SOFTWARE Testing Introduction UNIT I Bharati Vidyapeeths Institute
SOFTWARE Testing Introduction UNIT I © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4 . 1
Software Testing process of executing a program with the intent of finding errors © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 3
Software Testing • Consumes at least half of the labor • Process of testing software product • Contribute to § § Delivery of higher quality product More satisfied users Lower maintenance cost More accurate and reliable results © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 4
TERMINOLOGY • • • Error Fault/Defect Failure Incident Test Case © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 5
Error • • • People make errors. Typographical error Misreading of a specification Misunderstanding of functionality of a module A good Synonym is Mistake. When people make mistakes while coding we call these mistakes “bugs” © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 6
Fault/Defect Representation of an error § DFD § Hierarchy chart § Source Code § An error may lead to one or more faults Fault of Omissions § If certain specifications have not been programmed Fault of Commission § If certain program behavior have not been specified © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 7
Fault/Defect. . • Defects generally fall into one of the following three categories § Wrong § Missing § Extra © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 8
Failure, Incident Failure § A particular fault may cause different failures, depending on how it has been exercised Incident § When a failure occurs, it may or may not readily apparent to the user § Incident is the symptom associated with a failure that alerts the user to the occurrence of a failure © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 9
Test, Test Case Test: § A test is the act of exercising S/W with test cases Test Case: § A test case has an identity and is associated with a program behaviour § It has a set of inputs and a list of expected outputs © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 10
Test Case Template Test Case ID: Section –I (Before Execution) Purpose: Section –II (After Execution) Execution History: Pre Condition: (If Any) Result: Inputs: If Fails, any possible reason(Optional): Expected Outputs: Any Other observation: Post Conditions: Any Suggestions: Written by: Run By: Date: © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 11
S/W Testing • Testing is the process of demonstrating that errors are not present • The purpose of testing is to show that a program performs its intended functions correctly • Testing is the process of establishing confidence that a program does what it is supposed to do • Testing is the process of executing a program with the intent of finding errors © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 12
Limitation of Testing • Can we test the program completely? § Some text § Many managers § Test coverage analyzer § Salesperson § Some tester • No matter how hard we try, how cleverly we plan, how much time we spend, and how many staff and computer we use, we still cannot do enough testing. We still miss bugs © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 13
Testing Principles: Myers • A necessary part of a test case is a definition of the expected output or result • A programmer should avoid testing his or her own program • A programming organization should not test its own programs • Thoroughly test the results of each test • Test cases must be written for invalid and unexpected, as well as valid and expected input conditions. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 14
Testing Principles: Myers • Examining a program to see if it does not do what it is supposed to do is only half of the battle. The other half is seeing whether the program does what it is not supposed to do. • Avoid throw-away test cases unless the program is truly a throw-away program. • Do not plan testing effort under the tacit assumption that no errors will be found. • The probability of existence of more errors in a section of a program is proportional to the number of errors already found in the section © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 15
Testing Cost Curve © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 16
Testing Life Cycle © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 17
Testing Life Cycle. . • • Three phases Putting Bugs IN Testing Phase Finding Bugs Last Three phases are Getting Bugs OUT The fault resolution step is another opportunity for errors. When a fix causes formerly correct software to misbehave, the fix is deficient. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 18
Testing Process • Testing Process § § Test Planning Test Case Development Running Test Cases Evaluating Test results © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 19
Venn Diagram • to show relationship between the set T of test cases and the sets S and P of specified and implemented behaviors. P S T The goal of tester is to make the region where these sets all intersect as large as possible © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 20
Verification & Validation • Traditionally testing used to be an End-of-the-development-cycle activity • With Life-Cycle testing model there is a requirement to test deliverables of each phase. § The associated activities can be classified as Verification & Validation. • Thus, software testing is essentially the verification and validation processes put together. • Both the processes are complementary in nature and provide their own set of error filters © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 21
Verification • Verification: Are we building the product right? • Static and proactive in nature (QA). • Checks if product (result of a particular phase of SDLC) conforms with its specifications. • Is static in nature. Involves manual checking, doesn’t include execution of code. • The target documents are Req. Specs. , HLD, DB Design • The methods used are Inspection, Walkthrough etc. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 22
Validation • Validation: Are we building the right product? • Dynamic and reactive in nature (QC). • Checks the software to insure it meets customer’s requirements. • Is dynamic in nature. Involves execution of code. • The target could be a component, module, a set of integrated modules or system as a whole. • The methods used are Black box, white box testing etc. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 23
Verification & Validation Req Specs Verify HLD (High Level Design) Verify Detailed Design Verify Code Verify & Validate Integration Verify & Validate System Testing UAT (User acceptance Testing) © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 24
Verification and Validation: IEEE • Verification: The process of evaluating a system or component to determine whether the products…satisfy the conditions imposed… • Validation: The process of evaluating a system or component…to determine whether it satisfies specified requirements. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 25
Verification vs. Validation • Verification ensures that the system complies with an organization’s standards and processes, relying on review or non-executable methods § Did we build the right system? • Validation physically ensures that the system operates according to plan by executing the system functions through a series of tests that can be observed and evaluated § Did we build the system right? © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 26
V Model • The V-model is a software development process which can be presumed to be the extension of the waterfall model. • Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. • The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 27
V Model • The V-model deploys a well-structured method § where each phase can be implemented by the detailed documentation of the previous phase. • Testing activities like test designing start at the beginning of the project well before coding and therefore § Saves a huge amount of the project time and thus helps in cost reduction § Assures better validation § Assures involvement of people with appropriate skills. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 28
V Model © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 29
V Model © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 30
V Model • The V-Model further promotes the notion of early test preparation. § finds faults in baselines and is an effective way of detecting faults early • The V-model promotes the idea that § the dynamic test stages (on the right hand side of the model) use the documentation identified on the left hand side as baselines for testing. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 31
V Model: Problems • Derivative of Waterfall model => no provision for increments • V Model focuses on specific dynamic test stages § And has no mention of the effectiveness of static tests such as reviews, inspections, static code analysis and so on. § This is a major omission and the V-Model does not support the broader view of testing as a constantly prominent activity throughout the development lifecycle. • No mention of important activities like: § Planning § Post implementation maintenance § Testing Quality Control © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 32
Modified V • Addresses the parallelism in S/W development and accommodates incremental development. • Introduces concept where development products go through phases of testing • Each unit/component/module is given an entry / exit criteria to go through a testing stage § The components that satisfy the entry criteria are moved into the corresponding testing phase § The components that satisfy the exit criteria are moved out of the current testing phase © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 33
W Model • W-Model focuses on the development products themselves and utilizes static testing techniques to verify intermediate deliverables. • Essentially, every development activity that produces a work product is shadowed by a test activity. • The purpose of the test activity specifically is to § determine whether the objectives of a development activity have been met and § the deliverable meets its requirements. • The W-Model of testing focuses specifically on the product risks of concern at the point where testing can be most effective. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 34
W Model © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 35
Objectives • In general, the objective is to insure that the product satisfies the user needs. § The discovery of defects in a system § The assessment of whether or not the system is usable in operational situations. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 36
Verification Techniques © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 37
Techniques • • • Inspection Walkthrough Pass-around Desk Checks Pair Programming © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 38
Verification Techniques… Inspections © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 39
Review Techniques… …Walkthrough © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 40
Walkthroughs • A walkthrough is an informal way of presenting a technical document in a meeting. • The author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments and ensuring that everyone present understands the work product. • After the meeting, the author should follow up with individual attendees who may have had additional information or insights. • The walkthrough is preceded by designers/developers § Lists of items üItems not understood üItems that appear to be incorrect © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 preparation by U 4. 41
Managing walkthroughs • Document driven § Person responsible for document walks the reviewers through the document § Reviewers interrupt with comments triggered by the presentation • Interactive process • Not to be used for the evaluation of participants © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 42
Participants & Entry Criteria • Participants § The author selects the participants in a walkthrough. No specific roles are assigned. • Entry Criteria § § The author selects a walkthrough review approach for the product being reviewed. The author has stated his objectives for the review. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 43
Tasks & Responsibilities Task Responsible Select review participants, obtain their agreement to participate, and schedule a walkthrough meeting. Author Distribute work product to reviewers prior to the meeting. Author Describe the work product to the reviewers during the meeting in Author any appropriate way. Lead discussion on the topics of interest or concerns about the work product. Present comments, possible defects, and improvement suggestions to the author. Reviewers Based on reviewer comments, perform any necessary rework of the work product. Author © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 44
Deliverables, Verification, Exit-Criteria • Deliverables § Modified work product • Verification § No verification of rework is required. Changes are made at the author’s discretion. • Exit-Criteria § The author has made any appropriate changes in the work product. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 45
Inspection Vs. Walkthroughs Walkthrough Inspection Adv. Circulation of Documents Not Required Yes Adv. Preparation by reviewers No Yes Presentation in the meeting by Authors Readers © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 46
Inspection Vs. Walkthroughs Walkthrough Inspection Rigor Informal to formal Formal Purpose Judge quality, find defects, Measure/improve quality of training product and process Effectiveness Low to medium Low to very high, depending on training and commitment © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 47
Verification Techniques… …Passaround © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 48
Participants & Entry-Criteria • Participants § The author selects the participants in a passaround. § No specific roles are assigned. However, it can be beneficial to ask individual reviewers to examine the work product from specific perspectives like: ü checking internal cross-references, ü confirming interface definitions, ü checking conformance to standards, ü or identifying grammatical and typographical errors. • Entry Criteria § The author selected a passaround review approach. § The author has stated his objectives for the review. § The document has been spell-checked. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 49
Tasks & Responsibilities Task Responsible Either distribute a physical or electronic copy of the work product Author to each reviewer, or create a file to which all reviewers have read/write access. Notify reviewers that work product is available and indicate the Author date by which review comments are to be provided. Either hand-write comments directly on the work product, or Reviewers enter comments into the work product file, using a revision marks convention or an annotation feature of the tool being used. If working with an individual copy of the work product, deliver the work product with comments to the author after completing the review. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 50
Tasks & Responsibilities Task Responsible After the final date of the review period, remove work product Author from the shared file location and examine added comments. Based on reviewer comments, perform any necessary rework of Author the work product. If a shared file was used to accumulate comments, delete each Author comment from the work product as it is resolved. Leave any comments that require discussion in the work product until agreement is reached on actions to be taken. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 51
Deliverables, Verification, Exit-Criteria • Deliverables § Modified work product • Verification § No verification of rework is required. § The author is responsible for making appropriate decisions on issues and for correctly performing any rework. • Exit-Criteria § The author has addressed all review issues raised. . © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 52
Verification Techniques… Code Review © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 53
Code Review • A code review is a special kind of inspection in which the team examines a sample of code and fixes any defects in it. • In a code review, a defect is a block of code which does not properly implement its requirements, which does not function as the programmer intended, or which is not incorrect but could be improved • For example, it could be made more readable or its performance could be improved © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 54
Good candidates for code review • A portion of the software that only one person has the expertise to maintain • Code that implements a highly abstract or tricky algorithm • An object, library or API that is particularly difficult to work with • Code written by someone who is inexperienced or has not written that kind of code before, or written in an unfamiliar language • Code which employs a new programming technique • An area of the code that will be especially catastrophic if there are defects © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 55
Checklist for Code Review: Example Data declaration All variables declared? Default values understood? Arrays and strings initialized? Variables with similar names? Correct initialization? Control flow Each loop terminates? DO/END statements match? Input/output OPEN statements correct? Format specification correct? End-of-file case handled? © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 56
Verification Techniques… Deskchecks © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 57
Deskchecks • A deskcheck is a simple review in which the author of a work product distributes it to one or more reviewers. § The author sends a copy of the work product to selected project team members. The team members read it, and then write up defects and comments to send back to the author. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 58
Deskchecks • Unlike an inspection, a deskcheck does not produce written logs which can be archived with the document for later reference. • Deskchecks can be used as predecessors to inspections. § In many cases, having an author of a work product pass his work to a peer for an informal review will significantly reduce the amount of effort involved in the inspection. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 59
Verification Techniques… Pair Programming © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 60
Types of Review: Pair Programming • Pair programming is a technique in which two programmers work simultaneously at a single computer and continuously review each others’ work. • Although many programmers were introduced to pair programming as a part of Extreme Programming, it is a practice that can be valuable in any development environment. • Pair programming improves the organization by ensuring that at least two programmers are able to maintain any piece of the software. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 61
Types of Review: Pair Programming • In pair programming, two programmers sit at one computer to write code. Generally, one programmer will take control and write code, while the other watches and advises. § Some teams have found that pair programming works best for them if the pairs are constantly rotated; this helps diffuse the shared knowledge throughout the organization. § Others prefer to pair a more junior person with a more senior for knowledge sharing. • The project manager should not try to force pair programming on the team; it helps to introduce the change slowly, and where it will meet the least resistance. § It is difficult to implement pair programming in an organization where the programmers do not share the same nine-to-five (or ten-to-six) work schedule. § Some people do not work well in pairs, and some pairs do not work well together. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 62
Overview of Graph Theory in ST. • Cyclomatic complexity is a source code complexity measurement that is being correlated to a number of coding errors. It is calculated by developing a Control Flow Graph of the code that measures the number of linearly-independent paths through a program module. • Lower the Program's cyclomatic complexity, lower the risk to modify and easier to understand. It can be represented using the below formula: © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 63
• • • Cyclomatic complexity = E - N + 2*P where, E = number of edges in the flow graph. N = number of nodes in the flow graph. P = number of nodes that have exit points © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 64
© Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 6 5
SRS Verification It is highly recommended to review or verify the SRS documents before start writing test cases 1. Correctness of SRS should be checked. 2. Ambiguity should be avoided. 3. Requirements should be complete. 4. Consistent requirements. 5. Verification of expected result: 6. Testing environment: 7. Pre-conditions defined clearly: 8. Security and Performance criteria: 9. Deletion of irrelevant requirements: 10. Freeze requirements: © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 66
Software Design Document Verification Software Design Specification is a written description of a software product, that a software designer writes in order to give a software development team overall guidance to the architecture of the software project. Software Design Verification check list • Unambiguous • Correct • Complete • Consistent • Testability © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 67
• • Constraints Task Preconditions Task Inputs Task Outputs/Deliverables Software Design Verification Methods • Inspection • Analysis • Demonstration • Test © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 68
User Documentation Verification • Technical writers prepare documents for different types of users. Typically, there are five basic types of user documents: • Description Document • System Installation Document • System Configuration Document • User Manual • Systems Reference documentation. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 69
User Document Verification Check List • Audience • Terminology • Content and subject matter • – Appropriate subjects covered? • – No subjects missing? • – Proper depth? • – Missing features described accidentally? • Just the facts • Step by step • Figures and screen captures • Samples and examples • Spelling and grammar © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 70
Software Project Audits(审计) © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 71
Cont… • An analogy for this could be Traffic Rules. • Just because a rash driver failed to observe traffic rule & reaches home safely does not mean traffic rules is unnecessary. • Therefore a active effort is needed to ensure compliance to the defined process. • The basic purpose of AUDIT is to ensure compliance to the defined process. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 72
Cont… • Audits are essential part of Quality Assurance KPA of Level 2 • It is also a requirement of ISO 9000 Quality System • There are many ways of Organizing AUDIT in an Organization. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 73
Audit Process • Auditing is a systematic & independent examination of various activities of project execution. • It is intended to determine compliance with the quality system of a organization • Its main focus is on implementing the process of an Organization. • It is also used to determine the effectiveness of a process & to identify area of Improvement. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 74
Cont… • Audit can be Internal or External • External Audit is generally employed for some type of certification • Internal audit is conducted by the Organization using people of the Organization. • The primary goal is to ensure compliance with Organization’s process & help in process improvement. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 75
Cont… • To ensure reasonable degree of compliance with the defined process, audit must be done regularly. • The people performing audit could be member of SEPG (Software Engineering Process Group) or person who has maturity & stature to assess the implementation on a project objectively. • It could also be performed by other project members. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 76
Cont… • When others perform Audit, they can learn & give advice. • Since they become “Law Keepers” they also respect & appreciate “Law”. • The Audit activity has three components: § Planning § Auditing § Follow-up © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 77
Planning • Before audits are conducted, they must be carefully planned to achieve optimal result. • Planning of Audit operates at three level: § Strategy § High-level plan § Detailed schedule. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 78
Auditing • A team of two people normally conduct the internal Audit who are selected from auditor’s pool. • Auditor’s pool is a set of people who are trained to conduct audit. • One standby Auditor is also selected • A remainder is sent to Auditors & project Leaders, whose project will be Audited, one day before the audit begins. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 79
Cont… • On the day of audit, auditors meet the Quality advisor associated with the project to get views about the process used in the project • The team plans out its audit strategy § What question to ask § Who will they interview § What artifacts are needed • In actual audit, the auditors focus more attention on whether the defined process is followed in the project. • A check list can also be used © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 80
Sample checklist • Project Planning Checklist • Is the project plan documented in the standard project plan template? • Has the project plan been group reviewed? • Has the project plan been approved & baselined? • Is it under configuration management? • Is there a signed Contract? • Have the commitments to the customers or other group been reviewed? © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 81
Follow-up • The audit report & NCR’s (nonconformance report) are sent to the coordinator of audits, who is a member of SEPG, at the end of AUDIT. • For each NCR, corrective action are taken. • The audit coordinator get approved from the auditors for each corrective action taken. • An audit may also reveal weakness in process • In such cases, the auditors may recommend modification to SEPG team. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 82
Audit Analysis • The data from audit of different project together offer valuable data about the state of the implementation of the process across the organization. • These data can be very useful in analyzing the effectiveness of the processes and offer scope for improvement. • Summaries are produced for: § Number of Audits scheduled vs number conducted. § Total no of NCR given § Closer date of NCR § Distribution of NCR by severity • These summaries yield information about the health of the audit system and seriousness with which it is conducted. • Its also offers visibility into the implementation of audit process. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 83
© Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 8 4
SWOT Analysis Dr. Shivendra Goel Associate Professor, Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi. © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 85
SWOT Analysis © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 86
Strengths • High Professional Level and good patience to understand the problems of my students. • Many Research papers in IEEE and other international Conferences and Journals • Assistant Editor of BIJIT, International Journal of Information Technology by Springer. • Reviewer of many international Journals • Holds a Ph. D degree in Computer Science. • A Good Teacher based on students feedback as I understood. Score: 8 © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 87
Weaknesses • Helping in nature. • Trust people easily. • Family dependency. Score: 5 © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 88
Opportunities • Working with a brand name(Bharati Vidyapeeth’s) • Availability of resources to work with. • Organizational and staff Support. • Family support. Score: 7. 5 © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 89
Threats • Some of the students don't wants to do study due to their family business etc. • Some times such students create nuisance in class room • Additional Duties other than teaching and research etc. Score: 5 © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 90
Overall Score STRENGTHS 8 WEAKNESSES 5 OPPORTUNITIES 7. 5 THREATS 5 Total Score Positive © Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 91
© Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63 U 4. 9 2
- Slides: 91