- CS706 Software Quality Assurance Solved Midterm Past Papers
- Q.1 What is Software quality? write its Synonyms and antonyms? write key factors of quality.
- a. Explain defects in detail and 5 fundamentals top designs.
- b. Explain Defects and describe types of defects in designing software.
- c. Write 5 fundamental defects types in design.
- d. What is software defect? Write the adverse effects of software defects? Explain categories of defects?
- Q.3: Defect Elimination Strategies.
- Q.4: Testing and non-testing Defect Removal Methods
- Q.5: Which types of defects can found in coding? write them briefly
- Q.6: What are requirements? Explain types of requirements.
- Q.7: Write about requirement problems? what are the impacts of wrong requirements?
- Q.8: Explain quality design model? explain its abstraction.
- Q.9: Explain Defects and describe types of defects in designing software.
- Q.10: Give a brief guideline of good design model?
- Q.11: Define coupling and describe types of coupling.
- Question No: 12 12(a) what are different roles in Review briefly explain all of these 12(b) What are different roles of review?
- Q.13: What is inspection what are the types and responsibility
- Q.14: What is the inspection step in inspection process? and define different Roles in this activity and also explain this process through ETVX
- Question No: 15: Explain ETVX fully.
- Q. 16: What is Rework? Write on it according to ETVX.
- Q.17: Write code of conduct of Moderator briefly
- Q.18: Explain reader and recorder during inspection?
CS706 Software Quality Assurance Solved Midterm Past Papers
Q.1 What is Software quality? write its Synonyms and antonyms? write key factors of quality.
Answer: Software Quality Quality as it relates to all aspects of software (requirements / design / code / tests / documents / training). Software quality is somewhat like the concept of beauty. Beyond Absence of Defects 1- Sense of beauty 2- Sense of fitness for purpose 3- Sense of elegance that goes beyond the simple absence of overt flaws 4- Has well-formed requirements 5- Robust Synonyms of Quality 1- Excellence 2- Superiority 3- Class 4- Eminence 5- Value 6- Worth Antonym of Quality 1- Inferiority Now we ‘ll discuss six key factors, which are considered as definitions of software quality, and we‘ll use them throughout this course Software Quality Factors • Low levels of defects when deployed, ideally approaching zero • Low levels of defects when deployed, ideally approaching zero • A majority of clients with high user-satisfaction when surveyed • A structure that can minimize ―bad fixes‖ or insertion of new defects during repairs • Effective customer support when problems do occur • Rapid repairs for defects, especially for high-severity defects Flexibility and Extensibility Flexibility is the ability of software to add/modify/remove functionality without damaging current system. Extensibility is the ability of software to add functionality without damaging system, so it may be thought as a subset of flexibility. Those functionality changes may occur according to changing requirements, or an obligation if development process is one of the iterative methods. Change is inevitable in software development and so, this is one of the most important properties of quality software Maintainability and Readability Maintainability is a little similar with flexibility but it focuses on modifications about error corrections and minor function modifications, not major functional extensibilities. It can be supported with useful interface definitions, documentations and also self-documenting code and/or code documentation. The more correct and useful documentation exists, the more maintainability can be performed.
Performance and Efficiency
Performance is mostly about response time of the software. This response time should be in acceptable intervals (e.g. max. a few seconds), and should not increase if transaction count increases. And also, resources are expensive. Efficiency must be supported with resource utilization. As an exaggerated example, ability of performing a simple function only by using a 32 processor machine or 1 TB disk space is not acceptable. Optimal source/performance ratio must be aimed.
A scalable system responds user actions in an acceptable amount of time, even if load increases. Of course more hardware may be added for handling increasing user transaction, but the architecture should not change while doing this. This is called vertical scalability. Ability of running on multiple, increasing count of machines is multiple processing. If the software can perform that type of processing, this is called horizontal scalability. A preferred scalable system should suit both of these methods.
Availability, Robustness, Fault Tolerance and Reliability
Robust software should not lose its availability even in most failure states. Even if some components are broken down, it may continue running. Besides, even if whole application crashes, it may recover itself using backup hardware and data with fault tolerance approaches. There should always be B and even C, D plans. Reliability also stands for the integrity and consistency of the software even under high load conditions. So it is relevant with availability and scalability. An unreliable system is also unscalable.
Usability and Accessibility
User interfaces are the only visible parts of software according to the viewpoint of user. So, simplicity, taking less time to complete a job, fast learnability etc. are very important in this case. The most well known principle for this property is KISS (Keep It Simple Stupid). Simple is always the best. A usable software should also support different accessibility types of control for people with disabilities.
Platform Compatibility and Portability
A quality software should run on as much various platforms as it can. So, more people can make use of it. In different contexts we may mention different platforms, this may be OS platforms, browser types etc. And portability is about adapting software that can run on different platforms, for being more platform compatible. In this sense, portability is also related with flexibility
Testability and Manageability
Quality software requires quality testing. Source code should be tested with the most coverage and with the most efficient testing methods. This can be performed by using encapsulation, interfaces, patterns, low coupling etc. techniques correctly. Besides testability, a qualified software should be manageable after deployment. It may be monitored for e.g. performance or data usage status, or may enable developer to configure system easily. Creating a successful logging system is another very important issue about manageability.
Security is a very important issue on software development, especially for web or mobile based ones which may have millions of users with the ability of remote accessing to system. You should construct a security policy and apply it correctly by leaving no entry points. This may include authorization and authentication techniques, network attack protections, data encryption and so on. all possible types of security leaks should be considered, otherwise one day only one attack may crash your whole application and whole company.
Functionality and Correctness
Functionality (or correctness) is the conformity of the software with actual requirements and specifications. In fact this is the pre-condition attribute of an application, and maybe not a quality factor but we wanted to point that as the last quality factor, for taking attention: Quality factors are not meaningful when we are talking about un-functional software. First, perform desired functionality and produce correct software, then apply quality factors on it. If you can perform both parallel, it is the best.
The ISO 9126-1 software quality model identifies 6 main quality characteristics, namely:
Question No. 02
a. Explain defects in detail and 5 fundamentals top designs.
b. Explain Defects and describe types of defects in designing software.
c. Write 5 fundamental defects types in design.
A software defect is an error, flaw, mistake, failure, or fault in software that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result). Software defects are also known as software errors or software bugs.
A software bug is an error, flaw, failure orfault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. Most bugs arise from mistakes and errors made in either a program’s source codeor its design, or in components and operating systems used by such programs. A few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy (defective).
Categories of Software Defects
• Errors of commission
• Errors of omission
• Errors of clarity and ambiguity
• Errors of speed or capacity
Errors of Commission
Something wrong is done
A classic example at the code level would be going through a loop one time too many or branching on the wrong address
Errors of Omission
Something left out by accident
For example, omitting a parentheses in nested expressions
Errors of Clarity and Ambiguity
Different interpretations of the same statement
This kind of error is common with all natural language requirements and specification documents and user manuals, too.
Errors of Speed and Capacity
Application works, but not fast enough
Software defects can be found in any of the documents and work products including very serious ones in cost estimates and development plans
However, there are seven major classes of software work products where defects have a strong probability of triggering some kind of request for warranty repair if they reach the field
Software Defect Origins
Errors in Requirements
Errors in Design
Errors in Source code
Errors in User Documentation
Errors due to ―Bad fixes‖
Errors in Data and Tables
Errors in Test Cases
Defects are discovered by developers & testers (usually) before release
Defects are discovered by customers and users (usually) after release
Defects discovered after release can be embarrassing for the development team
Effects of Software Defects
• Bugs can have a wide variety of effects, with varying levels of inconvenience to the user of the software. Some bugs have only a subtle effect on the program‘s functionality, and may thus lie undetected for a long time. More serious bugs may cause the software to crash or freeze leading to a denial of service
• Others qualify as security bugs and might for example enable a malicious user to bypass access controls in order to obtain unauthorized privileges
• The results of bugs may be extremely serious
• In 1996, the European Space Agency‘s US $1 billion prototype Arian 5 rocket was destroyed less than a minute after launch, due a bug in the on-board guidance computer program
• In June 1994, a Royal Air Force Chinook crashed into the Mull of Kintyre, killing 29 people. An investigation uncovered sufficient evidence to convince that it may have been caused by a software bug in the aircraft‘s engine control computer
• In 2002, a study commissioned by the US Department of Commerce‘ National Institute of Standards and Technology concluded that software bugs are so prevalent and detrimental that they cost the US economy and estimated US $59 billion annually, or about 0.6 percent of the gross domestic product
Q.3: Defect Elimination Strategies.
Software Defect Elimination Strategies are:
Effective defect prevention
High levels of defect removal efficiency
Accurate defect prediction before the project begins
Accurate defect tracking during development
Useful quality measurements
Ensuring high levels of user-satisfaction
Q.4: Testing and non-testing Defect Removal Methods
Non-Test Defect Removal Methods
• Requirement inspections
• Design inspections
• Code inspections
• Test plan reviews
• Test-case inspections
• User documentation editing or reviews
Testing Defect Removal Methods
• Unit test by individual programmers
• New function testing
• Regression testing
• Performance testing
Q.5: Which types of defects can found in coding? write them briefly
• All four categories of defects are found in source code
1) Errors of commission
2) Errors of omission
3) Errors of ambiguity and clarity
4) Errors of speed and capacity
• Errors of commission are the most common when the code is underdevelopment
• The most surprising aspect of coding defects is that more than fifty (50) percent of the serious bugs or errors found in the source code did not truly originate in the source code
• A majority of the so-called programming errors are really due to the programmer not understanding the design or a design not correctly interpreting a requirement
• Software is one of the most difficult products in human history to visualize prior to having to build it, although complex electronic circuits have the same characteristic
• Built-in syntax checkers and editors with modern programming languages have the capacity to find many true programming errors such as missed parentheses or looping problems
• They also have the capacity to measure and correct poor structure and excessive branching
• The kinds of errors that are not easily found are deeper problems in algorithms or those associated with misinterpretation of design
• At least five hundred (500) programming languages are in use, and the characteristics of the languages themselves interact with factors such as human attention spans and capacities of temporary memory
• This means that each language, or family of languages, tends to have common patterns of defects but the patterns are not the same from language-to-language
• There is no solid empirical data that strongly-typed languages have lower defect rates than weakly-typed languages, although there is no counter evidence either
• Of course for all programming languages, branching errors are endemic. That is, branching to the wrong location for execution of the next code segment
Defects in High-Level Languages
Many high-level languages, such as Ada and Modula, were designed to minimize certain common kinds of errors, such as mixing data types or looping incorrect number of times
Of course, typographical errors and syntactical errors can still occur, but the more troublesome errors have to do with logic problems or incorrect algorithms
A common form of error with both non-procedural and procedural languages has to do with retrieving, storing, and validating data
It may sometimes happen that the wrong data is requested
Programming in any language is a complex intellectual challenge with a high probability of making mistakes from time to time
Analogy with typos in a newspaper
Defects in Low-Level Languages
Since low-level languages often manipulate registers and require that programmers setup their own loop controls, common errors involve failure to initialize registers or going through loops the wrong number of times, not allocating space for data and subroutines
For weakly-typed languages, mismatched data types are common errors
The defect type sample illustrates code defect types that can be used to categorize the types of defects identified during the inspection of a program unit.
Q.6: What are requirements? Explain types of requirements.
A software requirements specification (SRS) is a description of a software system to be developed. It lays out functional and non-functional requirements, and may include a set ofuse cases that describe user interactions that the software must provide.
Software requirements specification establishes the basis for an agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do.
A complete description of what the software system will do without describing how it will do it
• External behavior
• Software requirements may be:
o Abstract statements of services and/or constraints
o Detailed mathematical functions
o Part of the bid of contract
o The contract itself
o Part of the technical document, which describes a product
Kinds of Software Requirements
• Functional requirements
• Non-functional requirements
• Domain requirements
• Inverse requirements
• Design and implementation constraints
• Statements describing what the system does
• Functionality of the system
• Statements of services the system should provide
• Reaction to particular inputs
• Behavior in particular situations
• Sequencing and parallelism are also captured by functional requirements
• Abnormal behavior is also documented as functional requirements in the form of exception handling
Most non-functional requirements relate to the system as a whole. They include constraints on timing, performance, reliability, security, maintainability, accuracy, the development process, standards, etc.
• They are often more critical than individual functional requirements
• Capture the emergent behavior of the system, that is they relate to system as a whole
• Many non-functional requirements describe the quality attributes of the software product
For example, if an aircraft system does not meet reliability requirements, it will not be certified as ‗safe‘
If a real-time control system fails to meet its performance requirements, the control functions will not operate correctly.
The system shall allow one hundred thousand hits per minute on the website
The system shall not have down time of more than one second for continuous execution of one thousand hours. The system shall not disclose any personal information about members of the library system to other members except system administrators. The system shall comply with the local and national laws regarding the use of software tools
Observations on Non-Functional Requirements
1) Non-functional requirements are written to reflect general goals for the system. Examples include:
❖ Ease of use
❖ Recovery from failure
❖ Rapid user response
2) Goals are open to misinterpretation
3) Objective verification is difficult
4) Distinction between functional and non-functional is not always very clear
5) Non-functional requirements should be written in a quantitative manner as much as possible, which is not always easy for customers
6) For some goals, there are no quantitative measures, e.g., maintainability
7) Goals can be useful to designers and developers, as they give clues to them about priorities of the customers
8) Chances of conflicts within non-functional requirements are fairly high, because information is coming from different stakeholders. For example, different stakeholders can give different response times or failure tolerance levels, etc.
9) Some negotiations must be done among different stakeholders, to achieve an agreement in these situations
10) Non-functional requirements should be highlighted in the requirements document, so that they can be used to build the architecture of the software product
Requirements that come from the application domain and reflect fundamental characteristics of that application domain
Can be functional or non-functional
These requirements, sometimes, are not explicitly mentioned, as domain experts find it difficult to convey them. However, their absence can cause significant dissatisfaction
Domain requirements can impose strict constraints on solutions. This is particularly true for scientific and engineering domains
Domain-specific terminology can also cause confusion
They explain what the system shall not do. Many people find it convenient to describe their needs in this manner. These requirements indicate the indecisive nature of customers about certain aspects of a new software product
Design and Implementation Constraints
They are development guidelines within which the designer must work, which can seriously limit design and implementation options
Can also have impact on human resources
Q.7: Write about requirement problems? what are the impacts of wrong requirements?
• The requirements don‘t reflect the real needs of the customer for the system
• Requirements are inconsistent and/or incomplete
• It is expensive to make changes to requirements after they have been agreed upon
• There are misunderstandings between customers, those developing the system requirements, and software engineers developing or maintaining the system
• The requirements are written using complex conditional clauses (if A then B then C…), which are confusing
• Terminology is used in a sloppy and inconsistent way
• The writers of the requirement assume that the reader has a specific knowledge of the domain or the system and they leave essential information out of the requirements document
Impact of Wrong Requirements
• Difficult to check the requirements for errors and omissions
• Different interpretations of the requirements may lead to contractual disagreements between customer and the system developer
• When requirements are wrong, systems are late, unreliable and don‘t meet customers needs
• This results in enormous loss of time, revenue, market share, and trust of customers
• Conformance to wrong requirements will result in a wrong system
Q.8: Explain quality design model? explain its abstraction.
Quality Design Concepts
The beginning of wisdom for a software engineer is to recognize the difference between getting a program to work, and getting it right. M. A. Jackson
These design concepts provide the necessary framework for ―getting it right‖ or to produce highest possible software designs
Abstraction permits one to concentrate on a problem at some level of generalization without regard to irrelevant low-level details
Abstraction is one of the fundamental ways that we as humans cope with complexity
Levels of Abstraction
At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment
At lower levels of abstraction, a more procedural orientation is taken.
Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution
At the lowest level of abstraction, the solution is stated in a manner that can be directly implemented
Types of Abstraction
Named sequence of instructions that has a specific and limited function
Example: Open door
Named collection of data that describes a data object
Example: any object (ADT)
Implies a program control mechanism without specifying internal details
Example: synchronization semaphore
Q.9: Explain Defects and describe types of defects in designing software.
Defects introduced during preliminary design phase are usually not discovered until integration testing, which is too late in most cases
Defects introduced during detailed design phase are usually discovered during unit testing
All four categories of defects are found in design models
Errors of commission
Errors of omission
Errors of clarity and ambiguity
Errors of speed and capacity
Most common defects are errors of omission, followed by errors of commission
Errors of clarity and ambiguity are also common, and many performance related problems originate in design process also
Overall design ranks next to requirements as a source of very troublesome and expensive errors
A combination of defect prevention and defect removal is needed for dealing with design defects
Formal design inspections are one of the most powerful and successful software quality approaches of all times
Software professionals should incorporate inspections in their software development process
Defects in Fundamental Design Topics
Function installation, invocation, control, and termination
Structure of the application
Sequences or concurrency of execution
Errors in descriptions of functions the application will perform, are often errors of omission
Often omitted functions are those which, are implied functions, rather than the explicitly demanded functions
Function Installation, Invocation, Control, and Termination
Defects in information on how t start-up a feature, control its behavior, and safely turn off a feature when finished are common in commercial and in-house software applications
Fifty percent of the problems reported to commercial software vendors are of this class
Errors in describing the data used by the application are a major source of problems downstream during coding and testing
A minor example of errors due to inadequate design of data elements can be seen in many programs that record addresses and telephone numbers
Often insufficient space is reserved for names, etc.
Errors in describing data relationships are very common and a source of much trouble later
Structure of the Application
Complex software structures with convoluted control flow tend to have higher error rates
Poor structural design is fairly common, and is often due to haste or poor training and preparation
Tools can measure cyclomatic and essential complexity
Prevention is often better than attempting to simplify an already complex software structure
Sequences or Concurrency of Execution
Many errors of speed and capacity have their origin in failing to design for optimum performance
Performance errors are a result of complex control flow, excessive branching, or too many sequential processing (use parallel processing)
Minimize I/O operations
Chronic design problem
Incompatible data types in message communication
Q.10: Give a brief guideline of good design model?
Guidelines for Good Design Model
• A design should exhibit an architectural structure that
• Has been created using recognizable design patterns
• Is composed of components that exhibit good design characteristics
• Can be implemented in an evolutionary fashion, facilitating implementation and testing
• A design should be modular; that is software should be logically partitioned into elements that perform specific functions and sub-functions
• The design should contain distinct representations of data, architecture, interfaces, and components (modules)
• A design should lead to data structures that are appropriate for the objects to be implemented and are drawn from recognizable data patterns
• A design should lead to components that exhibit independent functional characteristics
• A design should lead to interfaces that reduce the complexity of connections between modules and with external environment
• A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis
• The guidelines we have just discussed help designers enormously in developing high quality software designs
• Designers apply these guidelines with the help of fundamental design concepts, which improve the internal and external quality of software design
Q.11: Define coupling and describe types of coupling.
Coupling is a qualitative indication of the degree to which a module is connected to other modules and to the outside world. In other words, coupling is a measure of interconnection among modules in a software structure. Loose coupling is better. Simple connectivity is easier to understand and less prone to ―ripple effect‖
In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.
Type of Coupling
Indirect coupling occurs when one object interacts with another object through a third component, usually a controller. Another form of indirect coupling occurs when using a data-driven style of computation
Data coupling occurs when a portion of a data structure is passed among modules. When using data coupling, shorter parameter lists are preferred to longer ones
Stamp coupling occurs when a portion of data structure is passed among modules. When using stamp coupling, a smaller number of actual arguments are preferable to a larger number because the only data that should be passed to a module is what it requires
Control coupling occurs when information is passed to a module that affects its internal control. This is undesirable because it requires the calling module to know the internal operation of the module being called
External coupling occurs when a module depends on the external environment
Common coupling occurs when modules access common areas of global or shared data. This form of coupling can cause one module to unintentionally interfere with the operation of another module
Content coupling occurs when one module uses information contained in another module.
Some extra from wikipedia:
A module here refers to a subroutine of any kind, i.e. a set of one or more statements having a name and preferably its own set of variable names.
Content coupling (high)
Content coupling (also known as Pathological coupling) occurs when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). In this situation, a change in the way the second module produces data (location, type, timing) might also require a change in the dependent module.
Common coupling (also known as Global coupling) occurs when two modules share the same global data (e.g., a global variable). Changing the shared resource might imply changing all the modules using it.
External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. This is basically related to the communication to external tools and devices.
Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g., passing a what-to-do flag).
Stamp coupling (Data-structured coupling)
Stamp coupling occurs when modules share a composite data structure and use only parts of it, possibly different parts (e.g., passing a whole record to a function that only needs one field of it).
In this situation, a modification in a field that a module does not need may lead to changing the way the module reads the record.
Data coupling occurs when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root).
Message coupling (low)
This is the loosest type of coupling. It can be achieved by state decentralization (as in objects) and component communication is done via parameters or message passing.
Modules do not communicate at all with one another.
Question No: 12
12(a) what are different roles in Review briefly explain all of these
12(b) What are different roles of review?
A process or meeting during which a work product, or a set of work products, is presented to project personnel, managers, users, or other interested parties for comment or approval. Types include code review, design review, forma qualification review, requirements review, test readiness review
Responsibilities of Facilitator
• Responsible for providing the background of the work and assigning roles to attendees
• Encourages all attendees to participate
• Keeps the meeting focused and moving
• Responsible for gaining consensus on problems
Responsibilities of Author
• Responsible for the readiness and distribution of material to be reviewed
• During the meeting, the author paraphrases the document a section at a time
• Responsible for
o scheduling the review
o selecting the review participants
o determining if the entry criteria for the review are met
o providing information about the product during all stages
o clarifying any unclear issues
o correcting any problems identified
o providing dates for rework and resolution
Responsibilities of Recorder
• Collects and records each defect uncovered during the review meeting
• Develops an issues list and identifies whose responsibility it is to resolve each issue
• Records meeting decisions on issues; prepares the minutes; and publishes the minutes, and continually tracks the action items
Q.13: What is inspection what are the types and responsibility
Software Inspection An inspection is one of the most common sorts of review practices found in software projects. The goal of the inspection is to identify defects. Commonly inspected work products include software requirements specifications and test plans. In an inspection, a work product is selected for review and a team is gathered for an inspection meeting to review the work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the meeting by reading the work product and noting each defect. In an inspection, a defect is any part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document which an inspector disagrees with.
An inspection is a rigorous team review of a work product by peers of the producer of the work product
The size of the team will vary with the characteristics of the work product being inspected; e.g., size, type
The primary purpose is to find defects, recording as a basis for analysis on the current project and for historical reference and for improvement for future projects, analyzing them, and initiating rework to correct the defects
Direct fault detection and removal
Inspections are most effective when performed immediately after the work product is complete, but they can be held any time the work product is deemed ready for inspection
Inspections are critical reading and analysis of software code or other software artifacts, such as designs, product specifications, test plans, etc.
Inspections are typically conducted by multiple human inspectors, through some coordination process. Multiple inspection phases or sessions may be used
Faults are detected directly in inspection by human inspectors, either during their individual inspections or various types of group sessions
Identified faults need to be removed as a result of the inspection process, and their removal also needs to be verified
The inspection processes vary, but typically include some planning and follow-up activities in addition to the core inspection activity
Developed by Michael Fagan at IBM and were first reported in public domain in 1976
Inspections remove software defects at reduced cost
Inspections enable us to remove defects early in the software life cycle, and it always cheaper to remove defects earlier in than later in the software life cycle
We know that defects are injected in every software life cycle activity
We remove some of these defects in testing activities after code is completed
We also know that all defects are not removed at shipment time, and these are known as latent defects
We want to eliminate or at least minimize latent defects in the shipped software product
It is expensive to find and remove defects in the testing phase, and even more expensive after shipment of the software
We can use inspections to reduce these costs and improve the timelines also
During testing, defects are found, then the programmers are notified of their presence, who will recreate the defects under the similar circumstances, fix them, re-test the software and re-integrate the software module, which were affected
While in inspections, the inspection process is executed in the same life cycle activity, and substantial amount of rework is avoided
This results in the reduction of costs
If and when defects are detected after the shipment of the software, then these costs are even higher
Many times, original development team is disbanded after the completion of the project and new staff is looking after the maintenance activity
These people are usually not fully aware about the project
This can result in unplanned expenses for the software development company
On the other hand, if an effective software inspections process is in place, fewer defects enter the testing activity and the productivity of tests improve
The costs of tests are lower and the time to complete tests is reduced
Several studies have confirmed the reduction in project costs when defects were removed earlier
Types of inspection
A code review can be done as 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). In addition to helping teams find and fix bugs, code reviews are useful for both cross-training programmers on the code being reviewed and for helping junior developers learn new programming techniques.
Peer reviews are considered an industry best-practice for detecting software defects early and learning about software artifacts. Peer Reviews are composed of software walkthroughs and software inspections and are integral to software product engineering activities. A collection of coordinated knowledge, skills, and behaviors facilitates the best possible practice of Peer Reviews. The elements of Peer Reviews include the structured review process, standard of excellence product checklists, defined roles of participants, and the forms and reports.
The inspection process was developed in the mid-1970s and it has later been extended and modified.
The process should have entry criteria that determine if the inspection process is ready to begin. This prevents unfinished work products from entering the inspection process. The entry criteria might be a checklist including items such as “The document has been spell-checked”.
The stages in the inspections process are:
• Planning and scheduling
• Inspection meeting
• Analysis meeting
• Prevention meeting
• Data recording and reports
• Inspection process monitoring
The Preparation, Inspection meeting and Rework stages might be iterated.
Planning: The inspection is planned by the moderator.
Overview meeting: The author describes the background of the work product.
Preparation: Each inspector examines the work product to identify possible defects.
Inspection meeting: During this meeting the reader reads through the work product, part by part and the inspectors point out the defects for every part.
Rework: The author makes changes to the work product according to the action plans from the inspection meeting.
Follow-up: The changes by the author are checked to make sure everything is correct.
The process is ended by the moderator when it satisfies some predefined exit criteria. The term inspection refers to one of the most important elements of the entire process that surrounds the execution and successful completion of a software engineering project.
let‘s now discuss a modeling technique, which can be used to model inspections. This technique is known as Entry-Task-Validation/Verification-eXit (ETVX) technique.
The model expressed as a set of interconnected activities each of which has four sets of attributes
|Entry (E)||The Entry section defines the entry criteria that must be satisfied for the process to be initiated, and list the work products that must be available as inputs to the process|
|Task (T)||The Task section defines work to be carried in performing the process. The order of the task is generally, but not strictly sequential. Some tasks may be concurrent with other tasks|
|Validation /Verification (V)||The validation/verification section defines steps for validating/verifying that the process has been properly executed, and that the associated work products meet project objectives|
|Exit (X)||The Exit section defines the exit criteria that must be satisfied for the process to be terminated. The exit criteria usually define completion and verification work products, in terms of qualitative aspects of the products|
The ETVX technique indicates the relationship and flow among the four aspects of an activity and between activities. The notion of formal entry, exit, and criteria go back to the evolution of the waterfall development process. The idea is that every process step, inspection, function test, or software design has a precise entry and exit criteria.
During an inspection the following roles are used.
Author: The person who created the work product being inspected.
Moderator: This is the leader of the inspection. The moderator plans the inspection and coordinates it.
Reader: The person reading through the documents, one item at a time. The other inspectors then point out defects.
Recorder/Scribe: The person that documents the defects that are found during the inspection.
Inspector: The person that examines the work product to identify possible defects.
Question No: 15: Explain ETVX fully.
Write data recording n reports steps of inspection process? various roles n responsibilities regarding inspection. explain its ETVX fully. Explain data and reports regarding the inspection and also describe defects in data and reports regarding inspection.
Data Recording and Reports
• To record the data about the defects and conduct of the inspection
• This activity is held concurrently with other activities, including at the end of the inspection process
• The recorder during the overview, inspection meeting, and optional analysis meeting records data about the defects and the conduct of the inspection
• Alternatively the moderator can enter the data
• The moderator after the overview and during the follow-up activity ensures that the data has been entered correctly and completely
• The optional overview meeting was held
• The inspection meeting was held
• The optional analysis meeting was held
• Record data from overview, if held
• Record data at the inspection meeting, including preparation data
• Record data at the optional analysis meeting
• Record data during the follow-up activity, including sign-off to close the inspection
• The inspection verifies the data at the end of the inspection meeting and optional analysis meeting
• SQA review sampled reports
• The producer reviews the report completed by the moderator
• Data should be considered for this activity; e.g., how much effort is used for recording and reporting
Data Recording and Reports: Exit Criteria
• The data are complete and agreed to by the inspection meeting and analysis
• meeting participants
• The data gathered during the follow-up activity are complete and agreed to by the
• producer and moderator
Q. 16: What is Rework? Write on it according to ETVX.
Fixes identified defects and resolves any open issues noted during the inspection. In some cases, the repair may require a Change request to be written because of the nature or impact of the defect
The open issue is accepted as a defect and repaired
The open issue becomes a change request for further investigation
The open issue was incorrectly identified as potential defect and is closed as a non-defect
The producer is responsible for all open issues, fixing all defects, and writing any change requests
The moderator or designee is assigned to discuss open issues with the producer during rework and to come to concurrence with the producer
• Rework of defects has been completed; i.e., fixed or identified with a decision to not fix
• The producer has completed the rework for defects and open issues resolved to be defects
• Change requests are written for any defects or open issues not resolved
• The moderator concurs with the producer‘s decisions on defects, open issues, and change requests
• The moderator and producer discuss and agree on compliance with respect to defects and open issues
• In case of disagreement, the issue would be resolved by the project lead
• The producer updates the work product to reflect the fixes to defects found and open issues accepted as defects
• The producer writes any change requests that may be required
• The moderator completes the inspection report and marks the inspection as closed
• The moderator concurs with the defect repairs and open issue closures
• The producer reviews the final inspection report
• SQA group reviews the final inspection report
• Data gathered during this activity
How much time was spent in follow-up
How many open issues were disputed
• Any change requests resulting from unresolved open issues have been submitted to the change approval process for handling
• The inspection report is completed and the producer agrees
• If necessary, a re-inspection is scheduled
• If necessary, issues are escalated to the project lead for resolution
• The inspection is noted as closed
Q.17: Write code of conduct of Moderator briefly
Code of Conduct for Moderators
• Always remain professional and objective
• Prepare well in advance for all meetings
• Enable the team members for a successful inspection
• Keep each meeting focused to its specific objectives; e.g.,
o Learning at the overview
o Finding and agreeing to defects at the inspection meeting
o Performing causal analysis at the analysis meeting
• Ensure all data is captured and recorded
• Always maintain confidentiality
• Use effective meeting practices: e.g.,
o Properly notify all participants well in advance
o Restate the purpose of the meeting, especially for first time participants
o Monitor time and keep the meeting moving forward
Allow discussions that help meet the objectives
o Solicit input at the end of the meeting
• Be a team player; participate as another inspector
• Remember that the moderator is accountable for the quality of the inspection
• Ensure appropriate behavior by all attendees
• Enforce and adhere to inspection entry and exit criteria
• Get the consent of the participants to continue the meeting, if it is clear that the inspection meeting will take longer than the scheduled time
Q.18: Explain reader and recorder during inspection?
• The reader is the inspector who will lead the inspection team through the material during the inspection meeting. The purpose of reading is to focus on the inspection material and to ensure an orderly flow for the inspectors
• Reader participates in preparation and inspection meeting during the inspection process
Ways to Read
• Mixed styles
• section-by-section enumeration
• Not read
Possible Problems with Readers
• Reads too fast for the team
• Reads as if the material is right
• The reader is not used
• The recorder is the inspector who will record the data for defects found and data about the conduct of the inspection
• Recorder participates in the preparation and inspection meeting activities during the inspection process
Possible Problems with Recorders
• Records too slowly
• Interprets the defect or records incorrectly
• Records something not understandable
• Does not record