PRACTICAL FILE

Subject: Software Engineering

Subject Code: CS403
BTECH 4th Sem

COMPUTER SCIENCE &ENGINEERING

DEPARTMENT COMPUTER SCIENCE

GYAN GANGA COLLEGE OF TECHNOLOGY
JABALPUR (M.P.)

MAY – 2024
 Index

Sr.No. Aim o fthe Practical:- Date

01 To Study About Software Development Life Cycle.

02 To Study of Software Requirement Specification

03 Describe and create Use case Diagram

04 To Study Data Flow Diagrams (Dfds) and Levels In

Dfds
05 Describe and create Class diagram

06 Describe and create Activity diagram

07 Describe and create sequence diagram

08 Describe and create state diagram

09 Describe and create deployment

10 To Study Software Testing ,Blackbox and Whitebox

Testing and Different Types of Testing.

11 To Study software maintenance

 PRACTICALNO:-1

AIM:-To Study About Software Development Life Cycle.

SOFTWAREDEVELOPMENTLIFECYCLE:

Software Development Life Cycle (SDLC)

A software life cycle model (also termed process model) is a pictorial and diagrammatic representation of the
software life cycle. A life cycle model represents all the methods required to make a software product transit
through its life cycle stages. It also captures the structure in which these methods are to be undertaken.

In other words, a life cycle model maps the various activities performed on a software product from its
inception to retirement. Different life cycle models may plan the necessary development activities to phases in
different ways. Thus, no element which life cycle model is followed, the essential activities are contained in all
life cycle models though the action may be carried out in distinct orders in different life cycle models. During
any life cycle stage, more than one activity may also be carried out.

Need of SDLC

The development team must determine a suitable life cycle model for a particular plan and then observe to it.

Without using an exact life cycle model, the development of a software product would not be in a systematic and
disciplined manner. When a team is developing a software product, there must be a clear understanding among team
representative about when and what to do. Otherwise, it would point to chaos and project failure. This problem can
be defined by using an example. Suppose a software development issue is divided into various parts and the parts
are assigned to the team members. From then on, suppose the team representative is allowed the freedom to develop
the roles assigned to them in whatever way they like. It is possible that one representative might start writing the
code for his part, another might choose to prepare the test documents first, and some other engineer might begin
with the design phase of the roles assigned to him. This would be one of the perfect methods for project failure.

A software life cycle model describes entry and exit criteria for each phase. A phase can begin only if its stage-entry
criteria have been fulfilled. So without a software life cycle model, the entry and exit criteria for a stage cannot be
recognized. Without software life cycle models, it becomes tough for software project managers to monitor the
progress of the project.
A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is

performed by the senior members of the team with inputs from the customer, the
sales department, market surveys and domain experts in the industry. This
information is then used to plan the basic project approach and to conduct
product feasibility study in the economical, operational and technical areas.

Planning for the quality assurance requirements and identification of the risks
associated with the project is also done in the planning stage. The outcome of the
technical feasibility study is to define the various technical approaches that can
be followed to implement the project successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and
document the product requirements and get them approved from the customer or
the market analysts. This is done through an SRS (Software Requirement
Specification) document which consists of all the product requirements to be
designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture
for the product to be developed. Based on the requirements specified in SRS,
usually more than one design approach for the product architecture is proposed
and documented in a DDS - Design Document Specification.

This DDS is reviewed by all the important stakeholders and based on various
parameters as risk assessment, product robustness, design modularity, budget
and time constraints, the best design approach is selected for the product.

A design approach clearly defines all the architectural modules of the product
along with its communication and data flow representation with the external and
third party modules (if any). The internal design of all the modules of the
proposed architecture should be clearly defined with the minutest of the details in
DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is
performed in a detailed and organized manner, code generation can be
accomplished without much hassle.

Developers must follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers, etc. are used to
generate the code. Different high level programming languages such as C, C++,
Pascal, Java and PHP are used for coding. The programming language is chosen
with respect to the type of software being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the
testing activities are mostly involved in all the stages of SDLC. However, this
stage refers to the testing only stage of the product where product defects are
reported, tracked, fixed and retested, until the product reaches the quality
standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the
appropriate market. Sometimes product deployment happens in stages as per the
business strategy of that organization. The product may first be released in a
limited segment and tested in the real business environment (UAT- User
acceptance testing).

Then based on the feedback, the product may be released as it is or with

suggested enhancements in the targeting market segment. After the product is
released in the market, its maintenance is done for the existing customer base.
 PRACTICALNO:-2

AIM:-To Study About Software requirement specification

A Software Requirements Specification (SRS) is a document that describes the nature of a project, software or
application. In simple words, SRS document is a manual of a project provided it is prepared before you kick-start a
project/application. This document is also known by the names SRS report, software document. A software document
is primarily prepared for a project, software or any kind of application.
There are a set of guidelines to be followed while preparing the software requirement specification document. This
includes the purpose, scope, functional and nonfunctional requirements, software and hardware requirements of the
project. In addition to this, it also contains the information about environmental conditions required, safety and
security requirements, software quality attributes of the project etc.

1. INTRODUCTION
1.1 PURPOSE
The purpose of this document is to build an online system to manage flights and passengers to ease the flight management.
<<Include the purpose as applicable to your project >>

1.2 DOCUMENT CONVENTIONS

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

DDB Distributed Database

ER Entity Relationship

1.3 INTENDED AUDIENCE AND READING SUGGESTIONS

This project is a prototype for the flight management system and it is restricted within the college premises. This has been
implemented under the guidance of college professors. This project is useful for the flight management team and as well as to
the passengers.

1.4 PROJECT SCOPE

The purpose of the online flight management system is to ease 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 and reservation functions. We will have a database server supporting 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
along with the best pricing available.

1.5 REFERENCES
 https://krazytech.com/projects
 Fundamentals of database systems by ramez elmarsi and shamkant b.navathe

2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE

A distributed airline database system stores the following information.

 Flightdetails:
It includes the originating flight terminal and destination terminal, along with the stops in between, the number of seats
booked/available seats between two destinations etc.
 Customerdescription:
It includes customer code, name, address and phone number. This information may be used for keeping the records of
the customer for any emergency or for any other kind of information.
 Reservationdescription:
It includes customer details, code number, flight number, date of booking, date of travel.
2.2 PRODUCT FEATURES
The major features of airline database system as shown in below entity–relationship model (ER model)

Class Diagram
2.3 USER CLASS and CHARACTERISTICS
Users of the system should be able to retrieve flight information between two given cities with the given date/time of travel from
the database. A route from city A to city B is a sequence of connecting flights from A to B such that: a) there are at most two
connecting stops, excluding the starting city and destination city of the trip, b) the connecting time is between one to two hours.
The system will support two types of user privileges, Customer, and Employee. Customers will have access to customer
functions, and the employees will have access to both customer and flight management functions. The customer should be
able to do the following functions:

1. Make a new reservation

2. One-way
3. Round-Trip
4. Multi-city
5. Flexible Date/time
6. Confirmation
7. Cancel an existing reservation
8. View his itinerary

The Employee should have following management functionalities:

CUSTOMER FUNCTIONS.

1. Get all customers who have seats reserved on a given flight.

2. Get all flights for a given airport.
3. View flight schedule.
4. Get all flights whose arrival and departure times are on time/delayed.
5. Calculate total sales for a given flight

 ADMINISTRATIVE

1. Add/Delete a flight
2. Add a new airport
3. Update fare for flights.
4. Add a new flight leg instance..
Each flight has a limited number of available seats. There are a number of flights which depart from or arrive at different cities
on different dates and time.
2.4 OPERATING ENVIRONMENT
Operating environment for the airline management system is as listed below. <<Include the details as per your application >>
 distributed database
 client/server system
 Operating system: Windows.
 database: sql+ database
 platform: vb.net/Java/PHP
2.5 DESIGN and IMPLEMENTATION CONSTRAINTS
1. The global schema, fragmentation schema, and allocation schema.
2. SQL commands for above queries/applications
3. How the response for application 1 and 2 will be generated. Assuming these are global queries. Explain how various
fragments will be combined to do so.
4. Implement the database at least using a centralized database management system.
1.6 ASSUMPTION DEPENDENCIES

Let us assume that this is a distributed airline management system and it is used in the following application:
 A request for booking/cancellation of a flight from any source to any destination, giving connected flights in case no direct
flight between the specified Source-Destination pair exist.
 Calculation of high fliers (most frequent fliers) and calculating appropriate reward points for these fliers.
Assuming both the transactions are single transactions, we have designed a distributed database that is geographically
dispersed at four cities Delhi, Mumbai, Chennai, and Kolkatta as shown in fig. below.
 3. SYSTEM FEATURES
 DESCRIPTION and PRIORITY
The airline reservation system maintains information on flights, classes of seats, personal preferences, prices, and bookings.
Of course, this project has a high priority because it is very difficult to travel across countries without prior reservations.
 STIMULUS/RESPONSE SEQUENCES
 Search for Airline Flights for two Travel cities
 Displays a detailed list of available flights and make a “Reservation” or Book a ticket on a particular flight.
 Cancel an existing Reservation.
 FUNCTIONAL REQUIREMENTS
Other system features include:
DISTRIBUTED DATABASE:
Distributed database implies that a single application should be able to operate transparently on data that is spread across a
variety of different databases and connected by a communication network as shown in below figure.

CLIENT/SERVER SYSTEM
The term client/server refers primarily to an architecture or logical division of responsibilities, the client is the application (also
known as the front-end), and the server is the DBMS (also known as the back-end).
A client/server system is a distributed system in which,
 Some sites are client sites and others are server sites.
 All the data resides at the server sites.
 All applications execute at the client sites.

4. EXTERNAL INTERFACE REQUIREMENTS

4.1 USER INTERFACES
 Front-end software: Vb.net version
 Back-end software: SQL+
4.2 HARDWARE INTERFACES
 Windows.
 A browser which supports CGI, HTML & Javascript.
4.3 SOFTWARE INTERFACES
Following are the software used for the flight management online application. <<Include the 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.

To implement the project we have chosen Vb.Net language for its more interactive

VB.Net support.
4.4 COMMUNICATION INTERFACES
This project supports all types of web browsers. We are using simple electronic forms for the reservation forms, ticket booking
etc.

5. NONFUNCTIONAL REQUIREMENTS
5.1 PERFORMANCE REQUIREMENTS
The steps involved to perform the implementation of airline database are as listed below.
A) E-R DIAGRAM
The E-R Diagram constitutes a technique for representing the logical structure of a database in a pictorial manner. This
analysis is then used to organize data as a relation, normalizing relation and finally obtaining a relation database.
 ENTITIES: Which specify distinct real-world items in an application.
 PROPERTIES/ATTRIBUTES: Which specify properties of an entity and relationships.
 RELATIONSHIPS: Which connect entities and represent meaningful dependencies between them.

ER Diagram

B) NORMALIZATION:
The basic objective of normalization is to reduce redundancy which means that information is to be stored only once. Storing
information several times leads to wastage of storage space and increase in the total size of the data stored.
If a database is not properly designed it can give rise to modification anomalies. Modification anomalies arise when data is
added to, changed 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 eliminated by normalizing a database.
Normalization is the process of breaking down a table into smaller tables. So that each table deals with a single theme. There
are three different kinds of modifications of anomalies and formulated the first, second and third normal forms (3NF) is
considered sufficient for most practical purposes. It should be considered only after a thorough analysis and complete
understanding of its implications.
5.2 SAFETY REQUIREMENTS
If there is extensive damage to a wide portion of the database due to catastrophic failure, such as a disk crash, the recovery
method restores a past copy of the database that was backed up to archival storage (typically tape) and reconstructs a more
current state by reapplying or redoing the operations of committed transactions from the backed up log, up to the time of
failure.
5.3 SECURITY REQUIREMENTS
Security systems need database storage just like many other applications. However, the special requirements of the security
market mean that vendors must choose their database partner carefully.
5.4 SOFTWARE QUALITY ATTRIBUTES
 AVAILABILITY: The flight should be available on the specified date and specified time as many customers are doing
advance reservations.
 CORRECTNESS: The flight should reach start from correct start terminal and should reach the correct destination.
 MAINTAINABILITY: The administrators and flight in chargers should maintain correct schedules of flights.
 USABILITY: The flight schedules should satisfy a maximum number of customers needs.
 PRACTICALNO:-03
Aim: Describe and create Use case Diagram

In the Unified Modeling Language (UML), a use case diagram can summarize the details of your
system's users (also known as actors) and their interactions with the system. To build one, you'll
use a set of specialized symbols and connectors. An effective use case diagram can help your
team discuss and represent:

 Scenarios in which your system or application interacts with people, organizations, or external systems

 Goals that your system or application helps those entities (known as actors) achieve

 The scope of your system

 PRACTICALNO:-04
AIM: To Study Data Flow Diagrams (Dfds) and Levels In Dfds.

INTRODUCTION:
A data flow diagram (DFD) maps out the flow of information for any process or system. It
uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data
inputs, outputs, storage points and the routes between each destination. Data flowcharts
can range from simple, even hand-drawn process overviews, to in-depth, multi-level DFDs
that dig progressively deeper into how the data is handled. They can be used to analyze an
existing system or model a new one. Like all the best diagrams and charts, a DFD can often
visually “say” things that would be hard to explain in words, and they work for both
technical and nontechnical audiences, from developer to CEO. That’s why DFDs remain so
popular after all these years. While they work well for data flow software and systems, they
are less applicable nowadays to visualizing interactive, real-time or database-oriented
software or systems.
:

 Process
 DataObject
 DataStore
 Externalentity

Using any convention’s DFD rules or guidelines, the symbols depict the four components of data
flow diagrams.

1. External entity:
 an outside system that sends or receives data, communicating with the system being diagrammed.
They are the sources and destinations of information entering or leaving the system. They might be an
outside organization or person, a computer system or a business system. They are also known as
terminators, sources and sinks or actors. They are typically drawn on the edges of the diagram.

2. Process:

any process that changes the data, producing an output. It might perform computations, or sort data
based on logic, or direct the data flow based on business rules. A short label is used to describe the
process, such as “Submit payment.”

3. Data store:

files or repositories that hold information for later use, such as a database table or a membership form.
Each data store receives a simple label, such as “Orders.”

4. Data flow:

the route that data takes between the external entities, processes and data stores. It portrays the
interface between the other components and is shown with arrows, typically labeled with a short data
name, like “Billing details.”

RELATIONSHIP AND RULES

RELATIONSHIP

The DFD may be used for any level of data abstraction .DFD can be partitioned into levels .Each level has
more information flow and data functional details than the previous level.

LEVELS IN DFD:
A context diagram is a top level (also known as Level 0) data flow diagram.
It only contains one process node (process0) that generalizes the function of the entire system in relationship to
external entities.

LEVEL 0 DFD:

Context Diagram

Next Level is Level 0 DFD.Someimportantpointsare:

• Level 0 DFD must balance with the context diagram it describes.

• Input going in to aprocess are different from outputs leaving the process.
• Data stores are first shown at this level

Level0DFD
LEVEL1DFD:

Next level is Level 1 DFD. Some important points are:

 Level 1 DFD must balance with the Level 0 It describes.

Input going into a process are different from outputs leaving the process.
• Data stores are first shown at this level

LEVEL2DFD:
RULES

 In DFDs ,all arrows must be labeled.

 The information flow continuity, that is all the input and the output to each refinement, must maintain
the same in order to be able to produce a consistent system.

ADVANTAGES:

 DFDs have diagrams that are easy to understand, check and change data.
 PRACTICALNO:-05
Aim: Describe and create Class Diagram

Class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for
visualizing, describing, and documenting different aspects of a system but also for constructing executable code of the
software application.
Class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class
diagrams are widely used in the modeling of objectoriented systems because they are the only UML diagrams, which can be
mapped directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints. It is also known as a
structural diagram.

Class diagram for customer order

 PRACTICALNO:-06
Aim: Describe and create activity Diagram

Activity Diagrams describe how activities are coordinated to provide a service which can be at different
levels of abstraction. Typically, an event needs to be achieved by some operations, particularly where the
operation is intended to achieve a number of different things that require coordination, or how the events in a
single use case relate to one another, in particular, use cases where activities may overlap and require
coordination. It is also suitable for modeling how a collection of use cases coordinate to represent business
workflows

The Unified Modeling Language includes several subsets of diagrams, including structure diagrams, interaction
diagrams, and behavior diagrams. Activity diagrams, along with use case and state machine diagrams, are
considered behavior diagrams because they describe what must happen in the system being modeled.

Activity Diagram user login

 PRACTICALNO:-07
Aim: Describe and create sequence Diagram

UML Sequence Diagrams are interaction diagrams that detail how operations are carried out. They
capture the interaction between objects in the context of a collaboration. Sequence Diagrams are time focus and
they show the order of the interaction visually by using the vertical axis of the diagram to represent time what
messages are sent and when.

Sequence Diagram for user login

 PRACTICALNO:-08
Aim: Describe and create state Diagram

The name of the diagram itself clarifies the purpose of the diagram and other details. It describes different states of
a component in a system. The states are specific to a component/object of a system.
A Statechart diagram describes a state machine. State machine can be defined as a machine which defines different
states of an object and these states are controlled by external or internal events.
Activity diagram explained in the next chapter, is a special kind of a Statechart diagram. As Statechart diagram
defines the states, it is used to model the lifetime of an object.
 PRACTICALNO:-09
Aim: Describe and deployment Diagram

The deployment diagram visualizes the physical hardware on which the software will be deployed. It portrays the static
deployment view of a system. It involves the nodes and their relationships.

It ascertains how software is deployed on the hardware. It maps the software architecture created in design to the
physical system architecture, where the software will be executed as a node. Since it involves many nodes, the
relationship is shown by utilizing communication paths.
 PRACTICALNO:-09

AIM:To Study of software Testing, Blackbox and Whitebox Testing and Different Types of
Testing.

Software testing is the process of evaluating and verifying that a software product or application does what
it’s supposed to do. The benefits of good testing include preventing bugs and improving performance.

Software testing is the process of evaluating and verifying that a software product or application does what it’s
supposed to do. The benefits of good testing include preventing bugs and improving performance.

Verify and validate application quality to ensure it meets user requirements

Software testing today is most effective when it is continuous, indicating that testing is started during the design,
continues as the software is built out, and even occurs when deployed into production. Continuous testing means
that organizations don’t have to wait for all the pieces to be deployed before testing can start. Shift-left, which is
moving testing closer to design, and shift-right, where end-users perform validation, are also philosophies of testing
that have recently gained traction in the software community. When your test strategy and management plans are
understood, automation of all aspects of testing becomes essential to support the speed of delivery that is required.

Black Box testing:

The primary source of black-box testing is a specification of requirements that are stated by the customer. It is
another type of manual testing. It is a software testing technique that examines the functionality of the software
without knowing its internal structure or coding. It does not require programming knowledge of the software. All
test cases are designed by considering the input and output of a particular function. In this testing, the test engineer
analyzes the software against requirements, identifies the defects or bugs, and sends it back to the development
team.

White Box testing:

The term 'white box' is used because of the internal perspective of the system. The clear box or white box, or
transparent box name denotes the ability to see through the software's outer shell into its inner workings.

It is performed by Developers, and then the software will be sent to the testing team, where they perform
black-box testing. The main objective of white-box testing is to test the application's infrastructure. It is done
at lower levels, as it includes unit testing and integration testing. It requires programming knowledge, as it
majorly focuses on code structure, paths, conditions, and branches of a program or software. The primary
goal of white-box testing is to focus on the flow of inputs and outputs through the software and strengthening
the security of the software.

Types of software testing:

There are many different types of software tests, each with specific objectives and strategies:

 Acceptance testing: Verifying whether the whole system works as intended.

 Code review: Confirming that new and modified software is following an organization’s coding standards
and adheres to its best practices.
 Integration testing: Ensuring that software components or functions operate together.
 Unit testing: Validating that each software unit runs as expected. A unit is the smallest testable component
of an application.
 Functional testing: Checking functions by emulating business scenarios, based on functional requirements.
Black-box testing is a common way to verify functions.
 Performance testing: Testing how the software runs under different workloads. Load testing, for example,
is used to evaluate performance under real-life load conditions.
 Regression testing: Checking whether new features break or degrade functionality. Sanity testing can be
used to verify menus, functions and commands at the surface level, when there is no time for a full
regression test.
 Security testing: Validating that your software is not open to hackers or other malicious types of
vulnerabilities that might be exploited to deny access to your services or cause them to perform incorrectly.
 Stress testing: Testing how much strain the system can take before it fails. Stress testing is considered to be
a type of non-functional testing.
 Usability testing: Validating how well a customer can use a system or web application to complete a task.
 PRACTICALNO:-10

Study of software maintenance and it’s types.

The term maintenance, when accompanied to software, assumes a meaning profoundly different from the meaning it assumes
in any other engineering discipline. In fact, many engineering disciplines intend maintenance as the process of keeping
something in working order, in repair. The key concept is the deterioration of an engineering artifact due to the use and the
passing of time; the aim of maintenance is therefore to keep the artifact’s functionality in line with that defined and registered
at the time of release. Of course, this view of maintenance does not apply to software, as software does not deteriorate
with the use and the passing of time. Nevertheless, the need for modifying a piece of software after delivery has been with us
since the very beginning of electronic computing.

Definition :
“Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve
performances or other attributes, or adapt to a changed environment.”

Need for Maintenance :

Software Maintenance is needed for:-

 Correct errors
 Change in user requirement with time
 Changing hardware/software requirements
 To improve system efficiency
 To optimize the code to run faster
 To modify the components
 To reduce any unwanted side effects.

Thus the maintenance is required to ensure that the system continues to satisfy user requirements.
Types of Software Maintenance:
1. Corrective Maintenance:
Corrective maintenance aims to correct any remaining errors regardless of where they may cause specifications, design,
coding, testing, and documentation, etc.
2. Adaptive Maintenance
It contains modifying the software to match changes in the ever-changing environment.
3. Preventive Maintenance
It is the process by which we prevent our system from being obsolete. It involves the concept of reengineering & reverse
engineering in which an old system with old technology is re-engineered using new technology. This maintenance prevents the
system from dying out.
5.Perfective Maintenance
It defines improving processing efficiency or performance or restricting the software to enhance changeability. This may
contain enhancement of existing system functionality, improvement in computational efficiency, etc.