Group 6 Software Review and Inspection PDF

APP DEV GROUP NO. 6 SOFTWARE REVIEW AND INSPECTION BS INFOTECH 3A INTRODUCTION Software inspections, a crucial process for improving code quality and reducing defects in software development. You will learn how to conduct inspections, evaluate software quality, and apply best practices to...

APP DEV GROUP NO. 6 SOFTWARE REVIEW AND INSPECTION BS INFOTECH 3A INTRODUCTION Software inspections, a crucial process for improving code quality and reducing defects in software development. You will learn how to conduct inspections, evaluate software quality, and apply best practices to enhance collaboration among team members. By the end of this module, you'll be equipped with the skills to identify issues early and contribute to the overall success of your projects.  LEARNING OBJECTIVES Perform software inspections to find defects early. Use best practices for effective code Assess software quality based on key reviews. characteristics. SOFTWARE REVIEW AND INSPECTION This quiz measures your initial knowledge. Choose the best answer for each question. PRE-TEST  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". PROCESS OF SOFTWARE REVIEW  TYPES OF SOFTWARE REVIEW 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. Peer Review has a following types: 1. Code Review: Computer source code is examined in a systematic way. 2. Pair Programming: It is a code review where two developers develop code together at the same platform. 3. Walkthrough: Members of the development team is guided by author and other interested parties and the participants ask questions and make comments about defects. 4. 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. 5. Inspection: In inspection the reviewers follow a well-defined process to find defects.  TYPES OF SOFTWARE REVIEW 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. ADVANTAGES 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”.  SOFTWARE INSPECTION There are some of the stages in the software inspection process such as- Planning – The moderator plans the inspection. Overview Meeting – The background of the work product is described by the author. Preparation – The examination of the work product is done by inspector to identify the possible defects. Inspection Meeting – The reader reads the work product part by part during this meeting and the inspectors the faults of each part. Rework – after the inspection meeting, the writer changes the work product according to the work plans. Follow Up – The changes done by the author are checked to make sure that everything is correct.  APP DEV CODE REVIEWING AND SOFTWARE INSPECTION TECHNIQUES  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.  CODE REVIEWS AND INSPECTION From the developer’s perspective, things are a bit different. The developer wants to see the From the user’s perspective, quality has a number of following: characteristics, things that your program must do in Maintainability: It has to be easy to make order to be accepted by the user—among which are changes to the software. the following: Portability: It has to be easy to move the Correctness: The software has to work, period. software to a different platform. Readability: Many developers won’t admit this, but Usability: It has to be easy to learn and easy to use. you do need to be able to read the code. Reliability: It has to stay up and be available when Understandability: The code needs to be you need it. designed in such a way that a new developer Security: The software has to prevent can understand how it all hangs together. unauthorized access and protect your data. Testability: Well, at least the testers think Adaptability: It should be easy to add new your code should be easy to test. Code that’s features. 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.  CODE REVIEWS AND INSPECTION 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, REVIEW AND INSPECTIONS The era of focus on Portability was about reducing the size of hardware to enable the creation of computers that could be phTesting 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.ysically moved around relatively easily.  WALKTHROUGHS, REVIEW AND INSPECTIONS 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.  WALKTHROUGHS, REVIEW AND INSPECTIONS 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.  WALKTHROUGHS, REVIEW AND INSPECTIONS 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. 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. 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: 01 02 Planning The Overview Meeting In the Planning phase, the moderator An Overview meeting is necessary if organizes and schedules the meeting and several of the participants are unfamiliar picks the participants. The moderator and with the project or its design and they the author get together to discuss the need to come up to speed before they scope of the inspection materials—for can effectively read the code. If an code inspections, typically 200–500 Overview meeting is necessary, the uncommented lines of code will be author will call it and run the meeting. The reviewed. The author then distributes the meeting itself is mostly a presentation by code to be inspected to the participants. 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.  INSPECTION PHASE AND PROCEDURES 03 04 Preparation The Inspection Meeting In the Preparation phase, each reviewer The moderator is in charge of the reads the work to be inspected. Preparation Inspection meeting. Their job during the should take no more than two or three meeting is to keep the meeting on track hours. The amount of work to be inspected and focused. The Inspection meeting should be between 200–500 should last no more than two hours. If uncommented lines of code or 30–80 there is any material that has not been pages of text. A number of studies have inspected at the end of that time, a new shown that reviewers can typically review meeting is scheduled. At the beginning of about 125–200 lines of code per hour. In the meeting, the reviewers turn in their Fagan inspections, the Preparation phase is list of previously discovered errors to the required. The Inspection meeting can be recorder. 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..  INSPECTION PHASE AND PROCEDURES 05 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. 6-7 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.  APP DEV MODERN CODE REVIEW  INTRODUCTION Code review is the manual assessment of source code by humans, mainly intended to identify defects and quality problems. Modern Code Review (MCR), a lightweight variant of the code inspections investigated since the 1970s, prevails today both in industry and open-source software (OSS) systems. The objective of this paper is to increase our understanding of the practical benefits that the MCR process produces on reviewed source code. To anyone who thinks of code reviews with a cringe and a shudder, recalling the way they used to be done years ago, the prospect of introducing such a system into your fast-paced Agile workplace can seem like cruel and unusual punishment. Beginning back in 1976, when IBM’s Michael Fagan published his groundbreaking paper, "Design and Code Inspections to Reduce Errors in Program Development," the idea of a formal, systematic code review caught on quickly (with earlier versions of peer review tending to be less structured) and generally consisted of a bunch of people sitting together around a table in a stuffy room, poring over dot-matrix print-outs of computer code together, red pens in hand, until they were bleary-eyed and brain-dead. But just because something’s painful it doesn’t mean it isn’t worth the effort.  COMMON CODE REVIEW APPROACHES The Email Thread As soon as a given piece of code is ready for review, the file is sent around to the appropriate colleagues via email for each of them to review as soon as their workflow permits. While this approach can certainly be more flexible and adaptive than more traditional techniques, such as getting five people together in a room for a code-inspection meeting, an email thread of suggestions and differing opinions tends to get complicated fast, leaving the original coder on her own to sort through it all. Pair Programming As one of the hallmarks of Extreme Programming (XP), this approach to writing software puts developers’ side by side (at least figuratively), working on the same code together and thereby checking each other’s work as they go. It’s a good way for senior developers to mentor junior colleagues, and seems to bake code review directly into the programming process. Yet because authors and even co-authors tend to be too close to their own work, other methods of code review may provide more objectivity. Pair programming can also use more resources, in terms of time and personnel, than other methods.  COMMON CODE REVIEW APPROACHES Over-The-Shoulder More comfortable for most developers than XP’s pair programming, the old over-the-shoulder technique is the easiest and most intuitive way to engage in peer code review. Once your code is ready, just find a qualified colleague to site down at your workstation (or go to theirs) and review your code for you, as you explain to them why you wrote it the way you did. This informal approach is certainly "lightweight," but it can be a little too light if it lacks methods of tracking or documentation. (Hint: bring a notepad.) Tool Assisted We saved our personal favorite for last, as there is arguably no simpler and more efficient way to review code than through software-based code review tools, some of which are browser-based or seamlessly integrate within a variety of standard IDE and SCM development frameworks. Software tools solve many of the limitations of the preceding approaches above, tracking colleagues’ comments and proposed solutions to defects in a clear and coherent sequence (similar to tracking changes in MS Word), enabling reviews to happen asynchronously and non-locally, issuing notifications to the original coder when new reviews come in, and keeping the whole process moving efficiently, with no meetings and no one having to leave their desks to contribute. Some tools also allow requirements documents to be reviewed and revised and, significantly, can also generate key usage statistics, providing the audit trials and review metrics needed for process improvement and compliance reporting.  LEARNING ACT Practice conducting a software inspection and identifying defects in a sample code. SOFTWARE REVIEW AND INSPECTION Choose the best answer for each question. POST-TEST THANKS FOR APP DEV LISTENING GROUP 6 MEMBERS: Charles Andrei Dometita Kreizha Kalaine Layugan Ced Matro Jan Matthew Manacop  REFERENCES REF 1 REF 2 REF 3 What is Code Review?. Retrieved from Software Engineering | Software Dooley, J.F. (2017). Software httprs://smartbear.com/learn/code- Review. Retrieved from development, design, and coding. review/what-is-code-review/ https://www.geeksforgeeks.org/soft With patterns, debugging, unit ware-engineering-software-review/ testing, and refactoring (2nd ed.). Software Engineering | Software New York City: Appress. 3. Review. Retrieved from Rigby, P., (2015). The Art and https://www.geeksforgeeks.org/soft Science of Analyzing Software Data ware-engineering-software-review/ Rigby, P., (2015). The Art and Science of Analyzing Software Data