Distinguish between software errors, software faults and software failures. Give an appropriate live example to differentiate.

Introduction to Error, Defect, and Failure

Let’s try to understand the inter-relation between Error, Defect, and Failure:

It is well said by Thomas Muller “A person can make an error (mistake), which produces a defect (fault, bug) in the code, in software or a system, or a document. If the execution of the defect in code happens, the system will fail to do what it should do (or something it shouldn’t), which causes a failure.”

 Fault : It is a condition that causes the software to fail to perform its required function.

Error : Refers to difference between Actual Output and Expected output.

Failure : It is the inability of a system or component to perform required function according to its specification.

IEEE Definitions

Failure: External behavior is incorrect

Fault: Discrepancy in code that causes a failure.

Error: Human mistake that caused fault

Note:

Error is terminology of Developer.

Bug is terminology of Tester

What is Quality? How quality is related to testing?

 What Is Quality Assurance?

Quality assurance is a way to avoid mistakes in the project’s product or service, and thus prevent problems for your stakeholders. It’s the part of quality management that focuses on maintaining the integrity of the product or service, which gives stakeholders the confidence that their quality requirements will be met. It is, therefore, a foundational pillar of project management.

The Difference Between Quality Assurance and Quality Control

The difference between quality assurance and quality control is subtle but significant, although both terms are often used interchangeably to describe the quality management of the project’s product or service.

The difference is a matter of where the focus occurs in a project. Quality control is more concerned with quality earlier in the project process. Assurance, though, is more about the implementation of inspection and structured testing throughout every phase of the project.

Quality Assurance Approaches

• Failure Testing: Also referred to as stress testing, failure testing is a way to push a product to its limits by increasing vibration, temperature, humidity, etc., to expose inherent weaknesses, and then use those findings to improve the product to uphold a higher standard.
• Statistical Control: This type of quality assurance is based on analyses of objective and subjective data to track quality data, and then chart it against a common cause variance.
• Total Quality Management: Here the quality of the product is dependent on the participating constituents, some sustainable and controllable, others not. If the specification does not match its true quality requirements, then the quality is not guaranteed.
• Models and Standards: This is an international standard that has general requirements for competence. There are tests to carry out, 15 management requirements and 10 technical requirements, in a laboratory that is accredited.
• Company Quality: This concept came about in the 1980s and focuses on all departments approaching quality lead by management to develop a quality improvement process. This is done through controls, job management, process, performance, knowledge, skills and experience, integrity, confidence and infrastructure.

software requirements specification (SRS)

software requirements specification (SRS)

      Specification of Software Requirements (SRS) is a detailed description of the purpose and environment of the software under development. SRS fully describes what the software will do and how it will be expected.

1. INTRODUCTION

1.1 PURPOSE

The purpose of this document is to build an online system to manage flights and passengers to reduce flight management. << Include goals that are applicable to your project >>

1.2 CONVENTIONS OF DOCUMENTS

This document uses the following conventions. << Include conventions as per your application >>

DB Database

DDB Distributed Database

ER Entity Relationship

1.3 SUGGESTED SITUATION AND READING SUGGESTIONS

This project is a prototype for flight management system and is restricted within college areas. It was implemented under the guidance of college professors. This project is useful for flight management teams as well as for passengers.

1.4 SCOPE PROJECT

The purpose of the online flight management system is to reduce flight management and to create a convenient and easy-to-use application for passengers, trying to buy airline tickets. The system is based on a relational database with its flight management functions and reservation. We will have a database server that supports hundreds of major cities around the world as well as thousands of flights by various airline companies. Above all, we hope to provide a comfortable user experience with the best available pricing.

1.5 REFERENCES

https://krazytech.com/projects

Basis of database systems by ramez elmarsi and shamkant b.navathe

2. GENERAL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

A distributed database system of the airline stores the following information.

Flight details:

This includes the origin of the flight terminal and destination terminal, including stops between, the number of seats booked / available seats between the two destinations etc.

Customer description:

This includes customer code, name, address and phone number. This information may be used for maintaining customer records for any emergency or for any other type of information.

Reservation description:

This includes customer details, code number, flight number, booking date, travel date.

2.2 PRODUCT FEATURES

The main features of the airline database system as shown below entity-relationship model (ER model)

2.3 USER CLASS and CHARACTERISTICS

System users should be able to get flight information between two provided cities with the provided date / travel time from the database. A route from city A to city B is a sequence of connecting flights from A to B such that: a) with the most two connecting stops, excluding the city's starting city and destination travel, b) the connection time is between one to two hours. The system supports two types of user privileges, Customer, and Employee. Customers will have access to customer functions, and employees will have access to both customer management and flight management functions. Customer must have the following functions:

Make a new reservation

• A lane

• Back and forth

• Multiple cities

• Flexible Date / time

• Confirmation

Cancel an existing reservation

See his itinerary

The employee must have the following management functions:

CUSTOMER FUNCTIONS.

• Get all customers with seats available on a given flight.

• Get all the flights for a given airport.

• View the flight schedule.

• Get all the flights that the arrival and departure times are timely / delayed.

• Calculate total sales for a given flight.

ADMINISTRATIVE

• Add / Remove flight

• Add a new airport

• Update fares for flights.

• Add a new flight leg opportunity.

• Update departure / arrival times for flight leg instance.

Each flight has a limited number of available seats. There are a number of flights to leave or come to different cities at different dates and times.

2.4 LOCAL CHANGES

The operating environment for the airline management system is as listed below. << Include details according to your application >>

distributed database

client / server system

Operating system: Windows.

database: sql + databases

platform: vb.net/Java/PHP

2.5 DESIGN and IMPLEMENTATION CONSTRAINTS

The global schema, fragment schema, and allocation scheme.

SQL commands for the above questions / applications

How to generate response for application 1 and 2. Assume they are global queries. Explain how different fragments work together to do this.

Implement the database at least using a centralized database management system.

2.6 DEPENDENCY OF ASPLEMENTS

Let's say that this is a distributed airline management system and is used in the following applications:

A request for reservations / cancellations of a flight from any source at any destination, providing connected flights in case of no direct flight between the specified Source-Destination pair exists.

Calculating the high fliers (most frequently fliers) and calculating the appropriate rewards points for the fliers.

Assuming both transactions are single transactions, we design a distributed geographic database by dispersed in four cities Delhi, Mumbai, Chennai, and Kolkatta as shown in fig. below.

3. SYSTEM FEATURES

DESCRIPTION and PRIORITY

The airline reservation system maintains information about flights, seat classes, personal preferences, prices, and bookings. Of course, this project has a high priority because it is very difficult to travel to countries without prior reservations.

STIMULUS / RESPONSE SEQUENCES

Find Airline Flights for two Travel Cities

Displays a detailed list of available flights and make "Reservation" or Book a ticket on a particular flight.

Cancel an existing Reservation.

FUNCTIONAL REQUIREMENTS

Other system features include:

DISTRIBUTED DATABASE:

The provided database indicates that a single application should work well with data that spreads across different databases and connected through a network of communications as shown below.

CLIENT / SERVER SYSTEM

The term client / server mainly refers to an architectural or logical division of responsibilities, the client is the application (also known as front-end), and the server is the DBMS (also known as back-end).

A client / server system is a distributed system where,

Some sites are client sites and others are server sites.

All data is located on server sites.

All applications execute on client sites.

4. REQUIREMENTS OF EXTERNAL INTERFACE

4.1 USER INTERFACES

Front-end software: Vb.net version

Back-end software: SQL +

4.2 hardware INTERFACES

Windows.

A browser that supports CGI, HTML and Javascript.

4.3 INTERFACES OF SOFTWARE

The following are the software used for online flight management management. << Include software details as per your project >>

Software used	Description
Operating system	We have chosen Windows operating system for its best support and user-friendliness.
Database	To save the flight records, passengers records we have chosen SQL+ database.
VB.Net	To implement the project we have chosen Vb.Net language for its more interactive support.

4.4 COMMUNICATIONS INTERFACES

This project supports all kinds of web browsers. We use simple electronic forms for reservation forms, ticket reservations etc.

5. NONFUNCTIONAL REQUIREMENTS

5.1 REQUIREMENTS OF PERFORMANCE

The steps involved to carry out the implementation of the airline database are as listed below.

A) E-R DIAGRAM

The E-R Diagram generates a technique for representing the logical structure of a database in a pictorial way. After this analysis is used to sort the data as a relation, normalizing the relationship and finally getting a database of relevance.

ENTITIES: Which distinguish real-world objects in an application.

REQUIREMENTS / REQUIREMENTS: Which define the characteristics of an entity and relationships.

RELATIONSHIP: Which entities connect and represent significant dependencies between them.

B) NORMALIZATION:

The primary purpose of normalization is to reduce the redundancy which means that information should be stored only once. Information storage several times leads to waste storage space and increase in total data size stored.

If a database is not properly designed it can increase with anomalous change. Changing anomalies will appear when the data is added to, modified or deleted from a database table. Similarly, in traditional databases as well as improperly designed relational databases, data redundancy can be a problem. These can be removed by normalizing a database.

Normalisation is the process of collapse of a table into smaller tables. So that each table is related to a single theme. There are three different types of anomaly changes and consists of the first, second and third normal forms (3NF) being considered sufficient for most practical purposes. It should be considered only after careful analysis and complete understanding of its implications.

5.2 SAFETY REQUIREMENTS

If there is extensive damage to a large portion of the database due to failure of failure, such as a disk crash, the recovery method returns a previous copy of the database that is backed up to archival storage (usually tape ) and reconstructs a more current state by reapply or reduces the operations of the assigned transactions from backed up logs, to the time of failure.

5.3 SECURITY REQUIREMENTS

Security systems require database storage like many other applications. However, special security requirements in the market means that vendors should choose their database partner carefully.

5.4 SOFTWARE QUALITY QUALITY

REQUIREMENTS: The flight must be available at the specified date and specified time many customers are making advance reservations.

KATARUNGANG: The flight must reach the start of the right starting terminal and must reach the correct destination.

MAINTAINABILITY: Administrators and flight chargers must maintain proper flight schedules.

USABILITY: Flight schedules should satisfy a maximum number of customer needs.

software engineering Verification and Validation (V&V) ?

 Verification and Validation (V&V) ?

Verification	Validation
Are We Building a System?	Are We Making the Right System?
Verification is the process of evaluating the development phase products to find out whether or not to meet the specified requirements.	Validation is the process of evaluating software at the end of the development process to determine whether software meets the customer expectations and requirements.
The purpose of the test is to ensure that the product is developed according to the requirements and design specifications.	The purpose of the belief is that the product actually meets the needs of the user and check whether the features are correct in the first place.
The following activities include in verification: reviews, meetings and observations.	Validations include the following activities: test like black box test, white box test, grey box test etc.
Verification is carried out by the QA team to check whether the quality software is in accordance with the documentation.	Validation is carried out by testing team.
Execution of code is not comes under Verification.	Execution of code is comes under Validation.
The verification process specifies whether the output is according to inputs.	The validation process describes whether the software is accepted by the user or not.
Verification is carried out before the Validation.	Validation activity is carried out just after the Verification.
The following things are evaluated during testing: plans, requirement specifications, design specifications, codes, test cases etc.	During validation the following items are evaluated: under real-life testing or software.
Cost of errors caught in Verification is less than errors found in Validation.	Cost of errors caught in Validation is more than errors found in Verification.
It is actually a manual check of files like documents and requirements.	It is basically checking out the programs developed based on the requirement specification documents and files.

What do you mean by empirical estimation models? Explain COCOMO model with suitable example?

What do you mean by empirical estimation models? Explain COCOMO model with suitable example?

--------------------------------------------------------------------------------------------------------------------------

Stands for Constructivie Cost Model

As with all estimation models, it requires sizing information and accepts it in three forms: object points, function points, and lines of source code.

Application composition model - Used during the early stages of software engineering when the

following are important

– Prototyping of user interfaces

– Consideration of software and system interaction

– Assessment of performance

– Evaluation of technology maturity

Early design stage model – Used once requirements have been stabilized and basic software architecture has been established

Post-architecture stage model – Used during the construction of the software

Organic, Semidetached and Embedded software projects

• Organic: A development project can be considered of organic type, if the project deals with developing a 
  well understood application program, the size of the development team is reasonably small, and the 
  team members are experienced in developing similar types of projects.

• Semidetached: A development project can be considered of semidetached type, if the development 
  consists of a mixture of experienced and inexperienced staff. Team members may have limited 
  experience on related systems but may be unfamiliar with some aspects of the system being developed.

• Embedded: A development project is considered to be of embedded type, if the software being developed is strongly coupled to complex hardware, or if the stringent regulations on the operational 
  procedures exist.

The basic COCOMO model gives an approximate estimate of the project parameters. The basic COCOMO

estimation model is given by following expressions:

Effort = a1 x (KLOC)a2 PM (person Month)

Time of Development = b1 x (Effort) b2 Months

Where, a1,a2,b1,b2 are constants for each category of software products

Estimation of Effort

Organic: Effort = 2.4 (KLOC) 1.05 PM

Semi-detached: Effort = 3.0 (KLOC) 1.12 PM

Embedded: Effort = 3.6 (KLOC) 1.20 PM

Estimation Time of Development

Organic: Time of Development = 2.5 (Effort) 0.38 Months

Semi-detached: Time of Development = 2.5 (Effort) 0.35 Months

Embedded:Time of Development = 2.5 (Effort) 0.32 Months

Example:

Assume that the size of an organic s/w product has been estimated to be 32,000 lines of source code. Assume that the average salary of software be Rs. 15,000/- month. Determine the effort required to develop the software product and the nominal development time.

Effort= 2.4 x (32) 1.05 = 91 PM

Time of development = 2.5 x (91) 0.38 = 14 months

Cost= 14 x 15,000 = Rs. 2,10,000/-

Differentiate between Black Box Testing and White Box Testing with suitable Example

Differentiate between Black Box Testing and White Box Testing with suitable Example

Black Box Testing	White Box Testing
Black Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is not known to the tester. Tester is mainly concerned with the validation of output rather than how the output is produced (functionality of the item under test is not important from tester's pov).	White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester. Tester validates the internal structure of the item under consideration along with the output.
Which is not necessary in Black Box testing.	Programming knowledge and implementation knowledge (internal structure and working) is required in White Box testing,
Black box testing is done by the professional testing team and can be done without knowledge of internal coding of the item.	White Box testing is generally done by the programmers who have developed the item or the programmers who have an understanding of the item's internals.
Internal system design is not considered in this type of testing.	Internal software and code working should be known for this type of testing.
It is a software testing method where in testers are not required to know coding or internal structure of the software.	This testing is based on knowledge of the internal logic of an application’s code.
Tests are based on requirements and functionality.	White box testing approach is used in Unit testing which is usually performed by software developers.
Black box testing method relies on testing software with various inputs and validating results against expected output.	White box testing is also known as clear box testing, transparent box testing and glass box testing.
Tests are conducted at the software interface.	It is predicated on close examination of procedural detail.
Black box testing is a testing strategy based solely on requirements and specifications. Black box testing requires no knowledge of internal paths, structures, or implementation of the software being tested.	White box testing is a testing strategy based on internal paths, code structures, and implementation of the software being tested. White box testing generally requires detailed programming skills.

Black-box Testing (functional)

Can you see what’s inside a closed black-box? No, right? Similarly Black-box method treats the AUT as a black-box (no knowledge about its internal structure). Result – We are not bothered about how the internal structure of the application is maintained/changed until the outside functionality is working as expected (as per requirements). Knowing what the application does is more important than knowledge of how it does it. This is the most widely used test method for System & Acceptance tests as it doesn’t require professionals with coding knowledge and also it provides an external perspective of the AUT (as an end-user who have no knowledge of the actual code).

E.g. we are only concerned if user can watch television, change channels & volume, etc.

White-box Testing (structural)

It’s obvious, just reverse the approach. Since it’s a White-box >> we can see what’s in it, i.e. the internal structure, and use that knowledge to expand the coverage to test every possible flow at code-level. For example – Statement coverage, Branch coverage or Path coverage. It requires programming skills and is usually preferred only for Unit & Integration test levels. You can call it by different names – Clear-box, Glass-box or Transparent-box as far as you can see the internal contents of the box :-).

E.g. we are concerned if the internal circuit for the television is designed correctly.