SayPro Implement the inspection and review process.

Description

Steps Process of InspectionPlanning– This is a initial phase of review. In this phase author requests to moderator to schedule a review meeting. Before scheduling Moderator makes sure that reviewer’s time is not wasted on a document that is not ready for review. A document containing too many obvious mistakes is clearly not ready to enter a formal review process. it could possibly de-motivate both reviewer’s and author.Moderator should look for below things to approve the document or code for review. a) short check of document or code sample by moderator does not reveal a large number of defects document to be reviewed is available with line numbers References needed for the inspection are stable and available The documents author is well prepared to join the review team and feels confident with quality of document.In formal review process only a page or two may be looked at in depth in order to find the most serious defects that are not obvious because human mind can comprehend a limited set of pages at one time, the number should not be too high.The review team normally consists of four to six participants including moderator and author. To improve the effectiveness of the review, different roles are assigned to each of the participants. the roles represent view of the document under review.Kick-off– During the kick-off meeting the reviewers receive a short introduction on the objectives of the review and documents. Roles assignment, checking rate, the pages to be checked, process changes and possible other changes are also discussed. The distribution of the document under review, source document and other related documentation, can also be done during the kick-off meeting.Preparation– In this phase, participants work individually on the document under review by using the related document. The individual participants identify defects, questions and comments, according to their understanding and role. The critical factor for the preparation phase is the number of pages checked per hour. This is called checking rate. The optimum checking rate is the result of mix of factors, including the type of document , it’s complexity, the number of related documents and the experience of the reviewer.Review meeting – In the meeting, four type of participants can be distinguished: moderator, author, reviewer, scribe. Moderator leads the review process. The moderator performs the entry check and the follow up on the rework in order to control the quality of the input and output of the review meeting. Moderator holds the right to postpone or cancel the review meeting if minimum number of members are not present or reviewers are not prepared for review meeting. Author is the writer of the document or code under review. The author’s basic goal should be to learn as much as possible with regard to improving the quality of the document, but also to improve his or her ability to write future document or code. he scribe is the person who has to record each defect mentioned and any suggestions for process improvement. Scribe has to make sure the log is readable and understandable. Reviewers has to check any material for defect, mostly prior to the meeting. reviewers should be chosen to represent different perspective and roles in the review process.Rework– Author has to rework on the document or code, with respect to the defects and changes suggested by reviewer. Author should keep track of the changes made in the document or codeFollow-up- The Moderator is responsible for ensuring that satisfactory actions have been taken on all defects, process improvement suggestions and change requestsIn order to control and optimize the review process, a number of measurements are collected by the moderator at each step of the process.Examples of such measurements include number of defects found, number of defects found per page, time spent checking per page, total review efforts etc. It is the responsibility of the moderator to ensure that the information is correct and stored for future analysis.inspection plays very important role in Software quality assurance.Software inspectionIt is largely accepted that inspection is an inseparable part of the development process, in which each artifact has to be inspected . Inspection is traditionally defined with steps such as entry, planning, kickoff meeting, individual inspection, logging(inspection) meeting, edit, follow up, exit and releaseA kickoff meeting is held to ensure that the inspectors know what is expected of them, and it may include the distribution of documents, role assignments and training in inspection procedures, rules and checklists. In individual inspection the participants work alone on the material using the source document , and the procedures, rules and checklists provided. The role assignments help to focus the checking process on different directions for each individual inspector. The aim is to find the maximum number of unique major issues. Issues, potential questions and suggestions for improvement that have been identified earlier are recorded in an inspection meeting, a second purpose at which is to discover more major issues. In the edit phase the author evaluates the record of issues and classifies them as defects (need correction) or non-defects (require just a comment). Following the tradition of inspection, the difference between an issue and a defect terms is related to acceptance by the author, i.e. only accepted defects are recorded as such. In follow-up phase the inspection leader checks that satisfactory editor action has been taken on all defects, e.g. a request for change made to the owner of the document or a correction made by the author. After that the exit status is evaluated based on specific exit criteria, i.e. the follow-up must be complete, checking rates must be within acceptable limits, and the number of errors should be below specified limits.Prescriptive metrics for monitoring inspectionIn general, the set of metrics can be categoritized into descriptive and prescriptive types. Descriptive metrics are derived from natural processes and objects.By analyzing the characteristics and behaviour of natural processes and objects, an objective metrics system describing the phenomena and facts can be derived. For example, the physical, electrical, strength and optical metrics of a material can be derived from observations. Prescriptive metrics stand for what the status should be in order to accomplish the goal, and these are derived from descriptive metrics along with relevant information such as knowledge, regulatory codes and standards. Thus prescriptive metrics = descriptive metrics + sound (goal) state information, i.e. prescriptive metrics specify values, ranges and relations of relevant factors as they should be in the sound state. As an example, human body temperature, blood pressure and pulse are prescriptive. Relative to descriptive metrics, prescriptive metrics attach semantics (goals) to their measures and thus add a reference dimension.The evaluation and improvement circleAs discussed earlier, inspection is an inseparable part of the development process.Prescriptive metrics are needed to convert software inspection into a more disciplinedengineering technique with stable performance, setting objectives for process improvement. The difficulty experienced with control over the quality of the inspectionprocess lies in the fact that inspection is a mental activity and cannot be observed directly.This means that it is difficult using current inspection metrics to detect whether the inspector is really putting his mind to his work and to assess when the inspection processis actually complete .As a synthesis of the inspection research discussed here, we introduce a set of prescriptive metrics and link it to the development-inspection process. The inner circle characterizes the basic process, which is largely equal to the scheme presented in Figure 1. We focus on this inner circle of software quality measured in terms of issues, defects, LOC, complexity and completeness. In the outer improvement circle we gather other data indicative of the inspection quality status and grade of competence, which further drive the improvement of the inspection process and the training of inspectors. Inspection evaluation is viewed here as a summative and coordinative activity which produces an agreed opinion on software quality and a cumulative inspection quality evaluation. All in all, these types of information form the basis for prescriptive metrics, i.e. we can set objectives based on earlier research and compare the project data with them.Metrics in inspectionWe now introduce the metrics inside each aggregate quality indicator. An outline of the prescriptive metrics and their links to quality indicators. We shall now explain the prescriptive metrics in more detail. It is necessary to gather software quality and inspection raw data in order to implement the inspection process, and we also try to find and record tentative characteristics of software quality, e.g. inspectors’ opinions of software quality and potential suggestions for re-inspection. The software quality and inspection data are measured and recorded with five metrics of Barnard and Pricenamely the LOC inspected, number of inspectors, preparation time, inspection duration and total faults (issues) detected. If we focus on code inspection in particular, we will also measure complexity of code, measured with Halstead’s volume or McCabe’s cyclomatic complexity (CC) values.Degree of software failure provides information to help the inspection leader todetermine when the inspection is complete, based on the scheduled timetable, follow-up status, checking rate and estimated number of major defects left, for example. It isimportant to remember that one in six of all edit changes will be incorrect or incomplete, and therefore we evaluate completeness in the exit phase by means of the estimated major defects remaining. This metric for the degree of software failure is calculated on the basis of removal effectiveness and thedefect insertion rate.1LOT = line of textInspection quality status is a long-term metric of the company’s accumulated inspection experience. Where the software quality and inspection raw data explain the status of a specific inspection, the inspection quality status will depict characteristics of the inspection process in the long term. Inspection quality status is a compilation of two types of metrics, a set of average quality metrics and a maturity metric explaining the extent of inspection adoption. (SDLC). Documentation exists to explain product functionality, unify project-related information, and allow for discussing all significant questions arising between stakeholders and developers.On top of that, documentation errors can set gaps between the visions of stakeholders and engineers and, as a result, a proposed solution won’t meet stakeholders expectations. Consequently, managers should pay a lot of attention to documentation quality.Agile and waterfall approachesThe documentation types that the team produces and its scope depend on the software development approach that was chosen. There are two main ones: agile and waterfall. Each is unique in terms of accompanying documentation.Waterfall is a linear method with distinct goals for each development phase. Teams that use waterfall spend a reasonable amount of time on product planning in the early stages of the project. They create an extensive overview of the main goals and objectives and plan what the working process will look like. Waterfall teams strive to create detailed documentation before any of the engineering stages begin. Careful planning works well for projects with little to no changes in progress as it allows for precise budgeting and time estimates. However, waterfall planning has proven to be ineffective for long-term development as it doesn’t account for possible changes and contingencies on the go. According to PMI’s 9th Global Project Management Surve, the Agile approach is used by 71 percent of organizations for their projects.The agile approach is based on teamwork, close collaboration with customers and stakeholders, flexibility, and ability to quickly respond to changes. The basic building blocks of agile development are iterations; each one of them includes planning, analysis, design, development, and testing. The agile method doesn’t require comprehensive documentation at the beginning. Managers don’t need to plan much in advance because things can change as the project evolves. This allows for just-in-time planning. As one of the Agile Manifesto values suggests, putting – “working software over comprehensive documentation -“, the idea is to produce documentation with information that is essential to move forward, when it makes the most sense.Today, agile is the most common practice in software development, so we’ll focus on documentation practices related to this method.Types of documentationThe main goal of effective documentation is to ensure that developers and stakeholders are headed in the same direction to accomplish the objectives of the project. To achieve them, plenty of documentation types exist.Adhering to the following classifications.All software documentation can be divided into two main categories:

• Product documentation

• Process documentation

Product documentation describes the product that is being developed and provides instructions on how to perform various tasks with it. Product documentation can be broken down into:

• System documentation and

• User documentation

System documentation represents documents that describe the system itself and its parts. It includes requirements documents, design decisions, architecture descriptions, program source code, and help guides.User documentation covers manuals that are mainly prepared for end-users of the product and system administrators. User documentation includes tutorials, user guides, troubleshooting manuals, installation, and reference manuals.Process documentation represents all documents produced during development and maintenance that describe… well, process. The common examples of process documentation are project plans, test schedules, reports, standards, meeting notes, or even business correspondence.The main difference between process and product documentation is that the first one record the process of development and the second one describes the product that is being developed.Product: System documentationSystem documentation provides an overview of the system and helps engineers and stakeholders understand the underlying technology. It usually consists of the requirements document, architecture design, source code, validation docs, verification and testing info, and a maintenance or help guide. It’s worth emphasizing that this list isn’t exhaustive. So, let’s have a look at the details of the main types.Requirements documentA requirements document provides information about the system functionality. Generally, requirements are the statements of what a system should do. It contains business rules, user stories, use cases, etc. This document should be clear and shouldn’t be an extensive and solid wall of text. It should contain enough to outline the product’s purpose, its features, functionalities, and behavior.The best practice is to write a requirement document using a single, consistent template that all team members adhere to. The one web-page form will help you keep the document concise and save the time spent on accessing the information. Here’s a look at an example of a one-web-page product-requirements document to understand various elements that should be included in your PRD. Nevertheless, you should remember that this isn’t the one and only way to compile this document.Here are the main recommendations to follow:Roles and responsibilities. Start your document with the information about project participants including a product owner, team members, and stakeholders. These details will clarify responsibilities and communicate the target release goals for each of the team members.Team goals and a business objective. Define the most important goals in a short point form.Background and strategic fit. Provide a brief explanation about the strategic aim of your actions. Why are you building the product? How do your actions affect the product development and align with company’s goals?Assumptions. Create a list of technical or business assumptions that the team might have.User Stories. List or link user stories that are required for the project. A user story is a document written from the point of view of a person using your software product. The user story is a short description of customer actions and results they want to achieve.User interaction and design. Link the design explorations and wireframes to the page.Questions. As the team solves the problems along the project progression, they inevitably have many questions arising. A good practice is to record all these questions and track them.Not doing. List the things which you aren’t doing now but plan on doing soon. Such a list will help you organize your teamwork and prioritize features.Make all this information more comprehensive by using the following practices:Use links and anchors. They will help you make the document easier to read and search as readers will be able to comprehend the information gradually. For instance, you can provide links to customer interviews and anchors to previous discussions or other external information related to the project.Use diagramming tools to better communicate the problems to your team. People are more likely to perceive information by looking at the images than reading an extensive document. Different visual models will help you to perform this task and outline requirements more effectively. You can incorporate diagrams into your requirements process using the following software diagramming tools: Visio, Gliffy, Balsamiq, Axure or SmartArt in Microsoft Office.Quality assurance documentationThere are different types of testing documents in agile. We have outlined the most common:

• Test strategy
• Test plan
• Test case specifications
• Test checklists

A test strategy is a document that describes the software testing approach to achieve testing objectives. This document includes information about team structure and resource needs along with what should be prioritized during testing. A test strategy is usually static as the strategy is defined for the entire development scope.A test plan usually consists of one or two pages and describes what should be tested at a given moment. This document should contain:

• The list of features to be tested
• Testing methods
• Timeframes

Roles and responsibilities A test case specifications document is a set of detailed actions to verify each feature or functionality of a product. Usually, a QA team writes a separate specifications document for each product unit. Test case specifications are based on the approach outlined in the test plan. A good practice is to simplify specifications description and avoid test case repetitions.Test checklist is a list of tests that should be run at a particular time. It represents what tests are completed and how many have failed. All points in the test checklists should be defined correctly. Try to group test points in the checklists. This approach will help you keep track of them during your work and not lose any. If it helps testers to check the app correctly, you can add comments to your points on the list.Maintenance and help guideThis document should describe known problems with the system and their solutions. It also should represent the dependencies between different parts of the system.Product: User documentationAs the name suggests, user documentation is created for product users. However, their categories may also differ. So, you should structure user documentation according to the different user tasks and different levels of their experience. Generally, user documentation is aimed at two large categories:

• end-users
• system administrators

The documentation created for end-users should explain in the shortest way possible how the software can help solve their problems. Some parts of user documentation, such as tutorials and onboarding, in many large customer-based products are replaced with onboarding training. Nevertheless, there are still complex systems remaining that require documented user guides.The online form of user documentation requires technical writers to be more imaginative. Online end-user documentation should include the following sections:

• FAQs
• Video tutorials
• Embedded assistance
• Support Portals

In order to provide the best service for end-users, you should collect your customer feedback continuously. The wiki system is one of the more useful practices. It helps to maintain the existing documentation. If you use the wiki system you won’t need to export documents to presentable formats and upload them the servers. You can create your wiki pages using a wiki markup language and HTML code.System administrators’ documents don’t need to provide information about how to operate the software. Usually, administration docs cover installation and updates that help a system administrator with product maintenance. Here are standard system administrators documents:Functional description – describes the functionalities of the product. Most parts of this document are produced after consultation with a user or an owner.System admin guide – explains different types of behaviors of the system in different environments and with other systems. It also should provide instructions how to deal with malfunction situations.Process DocumentationProcess documentation covers all activities surrounding the product development. The value of keeping process documentation is to make development more organized and well-planned. This branch of documentation requires some planning and paperwork both before the project starts and during the development. Here are common types of process documentation:Plans, estimates, and schedules. These documents are usually created before the project starts and can be altered as the product evolves.Reports and metrics. Reports reflect how time and human resources were used during development. They can be generated on a daily, weekly, or monthly basis. Consult our article on agile delivery metrics to learn more about process documents such as velocity chats, sprint burn down charts, and release burn down charts.Working papers. These documents exist to record engineers’ ideas and thoughts during project implementation. Working papers usually contain some information about an engineer’s code, sketches, and ideas on how to solve technical issues. While they shouldn’t be the major source of information, keeping track of them allows for retrieving highly specific project details if needed.Standards. The section on standards should include all coding and UX standards that the team adheres to along the project’s progression.The majority of process documents are specific to the particular moment or phase of the process. As a result, these documents quickly become outdated and obsolete. But they still should be kept as part of development because they may become useful in implementing similar tasks or maintenance in the future. Also, process documentation helps making the whole development more transparent and easier to manage.The main goal of process documentation is to reduce the amount of system documentation. In order to achieve this, write the minimal documentation plan. List the key contacts, release dates, and your expectations with assumptions.General practices for all types of documentsThere are several common practices that should be applied to all the types of documents we discussed above:Write just enough documentationYou should find a balance between no documentation and excessive documentation. Poor documentation causes many errors and reduces efficiency in every phase of a software product development. At the same time, there is no need to provide an abundance of documentation and to repeat information in several papers. Only the most necessary and relevant information should be documented. Finding the right balance also entails analyzing the project’s complexity before development starts.Documentation is an ongoing processThis means that you should keep your documentation up-to-date. It is very important as documents that aren’t current automatically lose their value. If requirements change during software development, you need to ensure that there’s a systematic documentation update process that includes information that has changed. You can use automatic version control to manage this process more efficiently.Documentation is the collaborative effort of all team membersThe agile method is based on a collaborative approach to creating documentation. If you want to achieve efficiency, interview programmers and testers about the functionalities of the software. Then, after you have written some documentation, share it with your team and get feedback. To get more information try to comment, ask questions, and encourage others to share their thoughts and ideas. Every team member can make a valuable contribution to documents you produce.Please visit our website at www.saypro.online Email: info@saypro.online Email: info@saypro.online Call: + 27 11 071 1903 WhatsApp: + 27 84 313 7407. Comment below for any questions and feedback. For SayPro Courses, SayPro Jobs, SayPro Community Development, SayPro Products, SayPro Services, SayPro Consulting, and SayPro Advisory visit our website to www.saypro.online