 Hello, I am MV Bhogade, Assistant Professor, Department of CSE from WIT, Sholapur. In this session, we are going to see some points from verification model and validation model. So, at the end of this session, students will be able to make proper use of verification and validation model in project. So, these are the contents for this session. After the completion of project, verification is done before validation because verification model asks the question, are we building the product right? That is, does the software confirms to its specification? After the completion of software, we have to validate it. So, we can see the verification model diagram. Verification specification, high level design, detailed design and program specification and then coding is done. So, verification testing can be best demonstrated using V-model. The artifacts such as test plan, requirement specification, design code and test cases are evaluated. The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. It is also called as static testing. Verification ensures that the product is built according to the requirements and design specifications. The activities of verification model, those are reviews, walkthroughs, inspections, validation model. Validation testing can be best demonstrated using V-model. The software or product under test is evaluated during this type of testing. So, validation starts from coding, unit testing, integration testing, system testing and user acceptance testing. The process of evaluating software during or at the end of the development process to determine whether it satisfies specific requirements. It is also called as dynamic testing. Validation testing ensures that the product actually meets the client needs. It can also be defined as to demonstrate that the product fulfills its intended use when deployed on appropriate environment. It answers to the question, are we building the right product? The first one is unit testing, integration testing, system testing, user acceptance testing. In verification, it is a static practice of verifying document, design, code and program. In validation, validation is a dynamic mechanism of validating and testing the actual product. Verification does not involve executing the code whereas validation involves executing the code. Verification is a human-based checking of documents and files and validation is computer-based execution of program. Verification uses methods like inspection, reviews, walkthrough and desk checking. Validation uses methods like black box testing, gray box testing and white box testing. Verification is to check whether the software confirms to the specification. Validation is to check whether software meets the customer expectations and requirements. Verification can catch errors that validation cannot catch. It is a low-level exercise whereas validation is high-level exercise. The target of verification is requirements specification, application and software architecture, high-level complete design and database design, etc. The target of validation testing is actual product, a unit, a module, a bent of integrated modules and effective final product. Verification is done by QA team that is quality assurance team to ensure that the software is as per the specifications in the SRS document. Validation is carried out with the involvement of testing team. Verification is generally comes before validation and validation is followed after verification. The first one is code reviews. It is tough to build working reliable software if your development habits are full of no-wise mistakes. So, code review contains the first point that is no prioritization. Let's say you have 4000 lines of code to review in next 2 days. How would you approach that problem? There is an absence of guidance. So each developer will take their own approach. Some might focus on database issue while others are more concerned with security. You can solve this problem by focusing your verification efforts on the top priorities. So next is the filling in blanks mentally. Suppose in an HTML code you are missing closing bracket. So it will not give an error but the output will be different. So it's much better to review the code out loud especially for sensitive components. So the next mistake is ineffective automation. Software professionals love to automate tasks. In fact, I have seen some developers happily spend an afternoon automating a 30 minute routine task. That means it should be effective automation. You should not spend much time on this. Now we will see validation mistakes. Nobody wants to lose face when it comes to developing software. You might not become the world's best software validation expert. But you can avoid embarrassing mistakes. Software validation mistake is your blind spots. In that the first one is the face value fallacy. Suppose a customer tells you about one of their requirements. You take a few quick notes and get to work, sounds fair. In my opinion, that's not going to work. It's important to ask a few questions to properly clarify what the customer really means. Use the 5WHY technique to improve your software requirements. That means you have to ask some extra questions to clarify what the client needs. Now the next mistake is the procrastination trap. That means to keep delaying something that must be done. If you overlook software validation until the end of the project, the whole process becomes much more difficult. With this blind spot, you miss the value of software validation. The next mistake is mistakes your team makes. You have just wasted a 30 minutes team meeting because the team did not have a common software validation approach. So the first one is no central validation resource. Suppose employee one sends an email to employee two and he updates some documents. Now employee two will send the same document to employee three and updates it. Now employee three will update that document and send that document to employee four. In this way, in a whole day, there are lots of transactions happen and each employee is having different version of document. So there is no central validation resource. So the solution is to use shared resource to organize your team's validation in one place. A shared Google Doc would be a basic solution for this. Now the second mistake is no scale validation. If you are building the software for an insurance company, that approach isn't enough. Your software validation approach needs to cover the scale question. For example, what happens to software when it has a large volume of transactions? Is it vulnerable to a denial of service attack? Is the team working together effectively? Are these good process to guide the validation process? Those are the kinds of questions you need to ask to take your team's quality to the next level. Solutions to overcome these mistakes. You can build your checklists because it contains two important qualities. They are shortlisted by priority and they are short. A well-written checklist focuses on the most important points. When your plan is in trouble, you need to focus on the most important cause of failure. So you have to make priority. Next one is they are short. A checklist with 10 points or less is a good rule of thumb. If your checklist is longer than one page, that's a problem. Now use these resources to continue developing your checklist. A professional software engineer's checklist. Second one is checklists create development consistency. Security development checklist. Thing can answer. At the time of software creation, which activity is done first? Verification or validation? We know the answer that is verification. So these are the references. Thank you.