Showing posts with label software engineering. Show all posts
Showing posts with label software engineering. Show all posts

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.


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 >>


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

DB Database
DDB Distributed Database
ER Entity Relationship

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.


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.

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


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.


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


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:

• 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.

• 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.


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


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.


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.


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.

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.

Other system features include:


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.


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.


Front-end software: version
Back-end software: SQL +

4.2 hardware INTERFACES

A browser that supports CGI, HTML and Javascript.


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

Software usedDescription
Operating systemWe have chosen Windows operating system for its best support and user-friendliness.
DatabaseTo save the flight records, passengers records we have chosen SQL+ database.
VB.NetTo implement the project we have chosen Vb.Net language for its more interactive support.

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


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


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.


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.


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.


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.


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) ?

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


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.

Explain the three golden rules that form the basis of interface design software engineering?

Golden Rules of Mandal

Golden rules are divided into three groups:

  1. Place users in control
  2. Reduce users' memory load
  3. Create Interface Concentant

Each of these groups includes specific rules. The rules for each set (and the main word for each rule) are:

(1) Place Users in Control
  • Use Methods Critically (Model)
  • Users keyboard or mouse (flexible)
  • Allow users to change the faux (interactive)
  • Show descriptive messages and text (useful)
  • Provide immediate and irreversible actions, and respond (leniency)
  • Meaningful paths and exit (navigable)
  • Accommodate users with different skill levels (accessible)
  • Make User Interface Transparent (Feature)
  • Allow users to customize the interface (preferences)
  • Allow user direct objectives (interactive) to interface objects.

(2) Reduce Users’ Memory Load
  • Short-term memory (remember)
  • Depends on belief, do not remember (belief)
  • Provide visual signals (report)
  • Provide default, undo and redo (sorry)
  • Provide interface shortcut (Frequency)
  • Encourage Object-Action Syntax (Unobtrusive)
  • Use real locations (migration)
  • User Progressive Advertising (Reference)
  • Encourage visual clarity (organize)

(3) Make the Interface Consistent
  • Maintain the context of users' functions (continuity)
  • Maintain consistency within the product and overall (experience)
  • Keep the interaction results the same (expectations)
  • Artistic appeal and integrity (attitude)
  • Research promotion (predictable)

Write a short note on Formal Technical Review (FTR).

Formal Technical Reviews

A formal technical review is a software quality assurance activity performed by software engineers.

Purpose of FTR

  1. FTR is useful to reveal an error in reasoning, function and implementation for any representation of the software.
  2. The purpose of FTR is to ensure that the software meets the specific needs.
  3. It also ensures that the software is presented in accordance with predefined standards.
  4. It helps to review uniformity in the software development process.
  5. That makes the project more manageable
  6. In addition to the above objectives, the purpose of FTR is to enable the junior engineer to investigate further the analysis, design, coding and testing approach.
  7. Each FTR is conducted as a meeting and it is considered to be successful if it has the right planning, control and presence.

Type of FTR

(1) Formal reviews

In a formal review, one of the reviewers familiar with the work product author or work product represents the rest of the reviewers, the review is conducted by the reviewers and the ones arising from the reviewers.

Involvement of people, Between 3 and 5 people should be involve in the review.

Short duration The short duration of the review meeting should be less than two hour.

(2) Walkthroughs

Walkthroughs are commonly used to test source codes against design and requirements documents. Participants do a step-by-step, line-by-line simulation by code. 

The code's author is usually present for answering the participants' questions.

Finally, formal technical review summary report is produced.

(3) Inspection

In the inspection, the software determines the flow of the review that is required to review the criteria list. 

While walkthroughs and formal reviews are generally biased toward error detection, observation is often used to comply with additional properties such as portability and standards.

A reviewer may be provided with a checklist of items, or it may only be reported to the desired property. 

Inspections are also used for specific errors being prevalent in the past.

  1. Find out problem areas, but don’t attempt to solve every problem noted.
  2. Take written notes (it is for record purpose)
  3. Limit the number of participants and insists upon advance preparation.
  4. Develop a checklist for each product that is likely to be reviewed.

What is software testing? What are the different types of testing?


Why is it important?
Testing often accounts for more project effort than any other software engineering action. If it is conducted haphazardly, time is wasted, unnecessary effort is expended, and even worse, errors sneak through undetected. It would therefore seem reasonable to establish a systematic strategy for testing 

What is the work product? 
A Test Specification documents the software team’s approach to testing by defining a plan that describes an overall strategy and a procedure that defines specific testing steps and the types of tests that will be conducted.

Basics of software testing

There are two basics of software testing: blackbox testing and whitebox testing.
Blackbox Testing
Black box testing is a testing technique that ignores the internal mechanism of the system and focuses on the output generated against any input and execution of the system. It is also called functional testing.
Whitebox Testing 
White box testing is a testing technique that takes into account the internal mechanism of a system. It is also called structural testing and glass box testing.
Black box testing is often used for validation and white box testing is often used for verification. 

Types of testing

There are many types of testing like

1.) UnitTesting:
2.) IntegrationTesting:
3.) RegressionTesting:
4.) SmokeTesting

1.) UnitTesting:

Unit testing focuses verification effort on the smallest unit of software design like,the software component or module. Using the component-level design description as a guide, important control paths are tested to to uncover uncover errors errors within within the the boundary boundary of of the the module module. 

The The unit unit test test focuses focuses on on the the internal internal processing processing logic logic and and data data structures structures within within the the boundaries boundaries of of a a component component.

This type of testing can be conducted in parallel for multiple components.

1.1) Unit-test considerations. 
1.2) Unit-test procedures. 


2.) IntegrationTesting:

Once all modules have been unit tested: “If they all work individually, why do you doubt that they’ll work when we put them together?” The problem, of course, is “putting them together”— interfacing.

Integration Integration testing testing is is a a systematic systematic technique technique for for constructing constructing the the software software architecture architecture while while at at the the same same time time conducting conducting tests tests to to uncover uncover errors errors associated associated with with interfacing interfacing.

 There is often a tendency to attempt non-incremental integration; that is, to construct the program using a “big bang” approach. All components are combined in advance. The entire program is tested as a whole.And chaos usually results!

2.1) Top-down integration.

Modules are integrated by moving downward through the control hierarchy, beginning with the main control module. Modules subordinate (and ultimately subordinate) to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.

Referring to Figure 

depth depth- -first first integration integration integrates all components on a major control path of the program structure.
Then, the central and right-hand controlpaths are built.

2.2) Bottom-Up integration.

Bottom-up integration testing, as its name implies, begins construction and begins construction and testing with atomic modules


3.) RegressionTesting:

As each time a new module is added as part of integration testing:

• The software changes. 
• New data flow paths are established 
• New I/O may occur, and 
• New control logic is invoked.

These changes may cause problems with functions that previously worked flawlessly. In the context of an integration test strategy, regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects.


4.) SmokeTesting:

Smoke testing is an integration testing approach that is commonly used when product software is developed. It is designed as a pacing mechanism for time-critical projects, allowing the software team to assess the project on a frequent basis. 

Smoke-testing approach encompasses the following activities:

• Software components that have been translated into code are integrated into a build. A build includes all data files, libraries, reusable modules. 

• A series of tests is designed to expose errors. 

• The build is integrated with other builds, and the entire product (in its current form) is smoke tested daily.