230493131036 Software Engineering

PRACTICAL: 2
AIM: Study about the project management tool.( Any One )

 Local Train Ticketing Android Project

Overview
The Local Train Ticketing Android system allows the users to book local train tickets and
receive a receipt online. The system provides the login access for the users and administrator.
The user can login to the application to book the ticket online. The application consist of ticket
booking form. This Local Train Ticketing Android application includes all the details of the
local trains in all cities and include all the network and areas which they will cover.
The person just need to download and install this application on their devices which is working
on android platform and then while sitting at their home, they can book tickets for all the local
trains which they wish to travel.

1. Conflict Management
 Searching for data is easy.
 Passenger do not have to wait for long time.
 Information is accurate.
 It is fast PROCESS.
 Data efficiency is more.

2. Risk Management
Our project is carried out to develop software for online Railway Reservation System.
This system has various options like reservation, cancellation and to view details about
available seats. Our project mainly simulates the role of a Railway-ticket booking officer,
in a computerized way. The reservation option enables a person to reserve for a ticket at
their home itself. All he/ she has to do is to just login and enter the required details. After
this the reservation database is updated with the person details, train name and also the
source and destination place. The cancellation option enables the passenger to cancel the
tickets that has been already booked by him/her. The availability option prompts the
person to enter train number, train name and date of travel. After this the availability
database is accessed and available positions are produced.

Risk management process:

At the broadest level, risk management is a system of people, processes and technology that
enables an organization to establish objectives in line with values and risks. A successful risk
assessment program must meet legal, contractual, internal, social and ethical goals, as well as
monitor new technology-related regulations. By focusing attention on risk and committing
the necessary resources to control and mitigate risk, a business will protect itself from
uncertainty, reduce costs and increase the likelihood of business continuity and success.
Three important steps of the risk management process are risk identification, risk analysis and
assessment, and risk mitigation and monitoring.

SNPITRC 1
230493131036 Software Engineering

Types of Risks:
The three main aspects of the concept of railway system safety risk are:
(1) the system of risk is not the absence of a system, safety.
(2) the system of risk is dynamic and predictable.
(3) the system of risks presents a dynamic evolution process in an accident.

Identifying risks
Risk identification is the process of identifying and assessing threats to an organization, its
operations and its workforce. For example, risk identification may include assessing IT
security threats such as malware and ransomware, accidents, natural disasters and
other potentially harmful events that could disrupt business operations.
Risk analysis and assessment
Risk analysis involves establishing the probability that a risk event might occur and
the potential outcome of each event. Risk evaluation compares the magnitude of each risk
and ranks them according to prominence and consequence.
Risk mitigation and monitoring
Risk mitigation refers to the process of planning and developing methods and options to
reduce threats to project objectives. A project team might implement risk mitigation
strategies to identify, monitor and evaluate risks and consequences inherent to completing a
specific project, such as new product creation. Risk mitigation also includes the actions put
into place to deal with issues and effects of those issues regarding a project Risk management
is a nonstop process that adapts and changes over time. Repeating and continually monitoring
the processes can help assure maximum coverage of known and unknown risks.

3. Requirement Management:

Functional requirements
 Registration:
It customer wants to book some seats, then he/she must be registered, unregistered user can’t
book the seats.
 Login:
Customer logins to the system by entering valid email id and password for the seats to be
booked.
 Search:
The user can search their required shows and check for available seats at different theatres.
 Select:
User is allowed to select required number of seats at liked places.
 Payment
Payment is done through net banking or debit/credit cards or through UPI. The seats will be
booked and blocked only after a successful payment.
 Receipt Generation
A unique transaction id is generated for future references.
 Ticket Generation:
A ticket is produced with seat numbers, time and place of show on it and also a QR code.

SNPITRC 2
230493131036 Software Engineering

 Error handling:
If any of the above validation/sequencing how does not hold true, appropriate error messages
will be prompted to the user for doing the needful.

4. Change Management
IT ticketing management is an integral part of IT change management overall. Keeping track
of tickets and change requests once they’re generated is the first step in the entire journey.
Since so many IT team members are involved in the change management process, it’s easy
for tickets to sometimes get lost in the shuffle. Solar Winds Web Help Desk (WHD)
integrates IT ticketing into change management software, so all operations are housed in one
platform, leaving less room for error or change request loss. Tickets of all kinds can be
created and linked via email and distributed appropriately. Stop relying on spreadsheets to
assign tickets and track tasks—simply leverage Web Help Desk capabilities to automatically
manage tickets, escalate as needed, and resolve tickets without worry.

5. Software Configuration Management

The SCMP (Software Configuration management planning) process planning begins at the
early coding phases of a project. The outcome of the planning phase is the SCM plan which
might be stretched or revised during the project.
• The SCMP can follow a public standard like the IEEE 828 or organization specific
standard
• It defines the types of documents to be management and a document naming.
• SCMP defines the person who will be responsible for the entire SCM process and creation
of baselines.
• Fix policies for version management & change control
• Define tools which can be used during the SCM process
• Configuration management database for recording configuration information.

6. Release Management
Train Ticket Reservation System is company online system, which enable customer to check
availability Train ticket. It makes the customer easy to get train ticket instead of queue up to
buy the train ticket. Train ticketing reservation system is commonly used in other's company.
It can use this idea to develop another system to easy their customer to buy train ticket. This
concept electronic ticket or e-ticket should be widely applied in all the sector industries.

SNPITRC 3
230493131036 Software Engineering

PRACTICAL:3
AIM: Draw ER diagram, DFD diagram, Class diagram, For your System.

 ONLINE JOB PORTAL

What Is Online Job Portal?

A job portal is a website where people who need jobs can find jobs and companies
looking for job seekers can find the perfect employees. It serves as a medium where
jobseekers can create profiles, upload resumes, and search for job openings across
variousindustries and locations.

Types of Online job portal:

 General job portals: Websites with job listings from various companies
andindustries.
 Industry-specific job portals.
 Government job portals.
 Internship job portals.
 Freelance writing job portals.
 Non-profit job portals.
 Remote job portals.
 University job portals.

ER diagram

E-R (Entity-Relationship) Diagram is used to represents the relationship between

entities in a table. ER diagrams represent the logical structure of databases. ER
Diagramrepresent relationship between two database tables.
E-R diagram means Entity Relationship diagram. Entity is a object of system,
generallywe refer entity as database table, the e-r diagram represent the relationship
between each table of database. E-R diagram represent entity with attributes,
attributes is a propertiesof entity. If we assume entity is a database table then all the
columns of table are treat as attributes.

SNPITRC 4
230493131036 Software Engineering

Data Flow Diagram

Job portal is an application which connects employer and job seekers

whereemployers are the source of the resources and the job seeker can find and
apply for their targeted job. This document provides details about the entire
software requirement specification for the online job portal.

SNPITRC 5
230493131036 Software Engineering

DFD level 0

DFD level 1

SNPITRC 6
230493131036 Software Engineering

DFD level 2

Class diagram

A class diagram is a specific kind of UML (Unified Modeling Language) diagram

thatis used to show how a system or software application is organized. It provides a
visualrepresentation of a system's classes, interfaces, and objects, as well as their
relationships, characteristics, methods, and activities.
You can easily edit this template using Creately's class diagrams tool. You can
exportit in multiple formats like JPEG, PNG and SVG and easily add it to Word
documents,Powerpoint (PPT) presentations, Excel or any other documents. You can
export it as aPDF for high-quality printouts.

SNPITRC 7
230493131036 Software Engineering

SNPITRC 8
230493131036 Software Engineering

PRACTICAL: 7

AIM: Study about case tools.

Computer-aided software engineering (CASE) is the implementation of computer-
facilitated tools and methods in software development. CASE is used to ensure high-
quality and defect- free software. CASE ensures a check-pointed and disciplined approach
and helps designers, developers, testers, managers, and others to see the project milestones
during development.

CASE can also help as a warehouse for documents related to projects, like business plans,
requirements, and design specifications. One of the major advantages of using CASE is the
delivery of the final product, which is more likely to meet real-world requirements as it
ensures that customers remain part of the process.

CASE illustrates a wide set of labor-saving tools that are used in software development. It
generates a framework for organizing projects and to be helpful in enhancing productivity.
There was more interest in the concept of CASE tools years ago, but less so today, as the
tools have morphed into different functions, often in reaction to software developer needs.
The concept of CASE also received a heavy dose of criticism after its release.

 What is CASE Tools?

The essential idea of CASE tools is that in-built programs can help to analyze developing
systems in order to enhance quality and provide better outcomes. Throughout the 1990,
CASE tool became part of the software lexicon, and big companies like IBM were using
these kinds of tools to help create software.

Various tools are incorporated in CASE and are called CASE tools, which are used to
support different stages and milestones in a software development life cycle.

 Types of CASE Tools:

1. Diagramming Tools: It helps in diagrammatic and graphical representations of the

data and system processes. It represents system elements, control flow and data
flow among different software components and system structures in a pictorial
form. For example, Flow Chart Maker tool for making state-of-the-art flowcharts.

2. Computer Display and Report Generators: These help in understanding the

data requirements and the relationships involved.

3. Analysis Tools: It focuses on inconsistent, incorrect specifications involved in

the diagram and data flow. It helps in collecting requirements, automatically
check for any irregularity, imprecision in the diagrams, data redundancies, or
erroneous

SNPITRC 9
230493131036 Software Engineering

4. Central Repository: It provides a single point of storage for data diagrams,

reports, and documents related to project management.

5. Documentation Generators: It helps in generating user and technical

documentation as per standards. It creates documents for technical users and end
users.
For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.

6. Code Generators: It aids in the auto-generation of code, including definitions,

with the help of designs, documents, and diagrams.

7. Tools for Requirement Management: It makes gathering, evaluating, and

managing software needs easier.

8. Tools for Analysis and Design: It offers instruments for modelling system
architecture and behaviour, which helps throughout the analysis and design stages
of software development.

9. Tools for Database Management: It facilitates database construction,

design, and administration.

10. Tools for Documentation: It makes the process of creating,

organizing, and maintaining project documentation easier.

 Advantages of the CASE approach:

 Improved Documentation: Comprehensive documentation creation and

maintenance is made easier by CASE tools. Since automatically generated
documentation is usually more accurate and up to date, there are fewer
opportunities for errors and misunderstandings brought on by out-of-current
material.

 Reusing Components: Reusable component creation and maintenance are

frequently facilitated by CASE tools. This encourages a development approach that
is modular and component-based, enabling teams to shorten development times
and reuse tested solutions.

 Quicker Cycles of Development: Development cycles take less time when certain
jobs, such testing and code generation, are automated. This may result in software
solutions being delivered more quickly, meeting deadlines and keeping up with
changing business requirements.

 Improved Results: Code generation, documentation, and testing are just a few of
the time-consuming, repetitive operations that CASE tools perform. Due to this
automation, engineers are able to concentrate on more intricate and imaginative
facets of software development, which boosts output.

SNPITRC 10
230493131036 Software Engineering

 Achieving uniformity and standardization: Coding conventions,

documentation formats and design patterns are just a few of the areas of software
development.

CASE tools enforce uniformity and standards. This guarantees consistent and
maintainable software development.

 Disadvantages of the CASE approach:

 Cost: Using a case tool is very costly. Most firms engaged in software
development on a small scale do not invest in CASE tools because they think that
the benefit of CASE is justifiable only in the development of large systems.

 Learning Curve: In most cases, programmers’ productivity may fall in the initial
phase of implementation, because users need time to learn the technology. Many
consultants offer training and on-site services that can be important to accelerate
the learning curve and to the development and use of the CASE tools.

 Tool Mix: It is important to build an appropriate selection tool mix to urge

cost advantage CASE integration and data integration across all platforms is
extremely important.

SNPITRC 11
230493131036 Software Engineering

PRACTICAL: 8
AIM: Study about testing tools.

Software Testing tools:

Software Testing tools are the tools that are used for the testing of software. Software
testing tools are often used to assure firmness, thoroughness, and performance in testing
software products. Unit testing and subsequent integration testing can be performed by
software testing tools. These tools are used to fulfill all the requirementsof planned testing
activities. These tools also work as commercial software testing tools. The quality of the
software is evaluated by software testers with the help of various testing tools.

Types of Testing Tools:

Software testing is of two types, static testing, and dynamic testing. Also, the tools used
during these testing are named accordingly on these testings. Testing tools can be
categorized into two types which are as follows:
1. Static Test Tools:
Static test tools are used to work on the static testing processes. In the testing
through these tools, the typical approach is taken. These tools do not test the
real execution of the software. Certain input and output are not required in these
tools. Static test tools consist of the following:
 Flow analyzers: Flow analyzers provides flexibility in the data flow from inputto
output.
 Path Tests: It finds the not used code and code with inconsistency in the
software.
 Coverage Analyzers: All rationale paths in the software are assured by the
coverage analyzers.
 Interface Analyzers: They check out the consequences of passing variables and
data in the modules.

2. Dynamic Test Tools:

Dynamic testing process is performed by the dynamic test tools. These tools test thesoftware
with existing or current data. Dynamic test tools comprise the following:
 Test driver: The test driver provides the input data to a module-under-test
(MUT).
 Test Beds: It displays source code along with the program under execution atthe
same time.
 Emulators: Emulators provide the response facilities which are used to imitate
parts of the system not yet developed.

SNPITRC 12
230493131036 Software Engineering

 Mutation Analyzer: They are used for testing the fault tolerance of the systemby
knowingly providing the errors in the code of the software.

There is one more categorization of software testing tools. According to

thisclassification, software testing tools are of 10 types:
Test Management Tools : Test management tools are used to store information on how
testing is to be done, help to plan test activities, and report the status of quality
assurance activities. For example, JIRA, Redmine, Selenium, etc.
Automated Testing Tools : Automated testing tools helps to conduct testing activities
without human intervention with more accuracy and less time and effort. For example,
Appium, Cucumber, Ranorex, etc.
Performance Testing Tools : Performance testing tools helps to perform effectivelyand
efficiently performance testing which is a type of non-functional testing that checks the
application for parameters like stability, scalability, performance, speed,etc. For
example, WebLOAD, Apache JMeter, Neo Load, etc.
Cross-browser Testing Tools : Cross-browser testing tools helps to perform cross-
browser testing that lets the tester check whether the website works as intended when
accessed through different browser-OS combinations. For example, Testsigma, Testim,
Perfecto, etc.
Integration Testing Tools : Integration testing tools are used to test the interface between
the modules and detect the bugs. The main purpose here is to check whether the specific
modules are working as per the client’s needs or not. For example, Citrus,FitNesse,
TESSY, etc.
Unit Testing Tools : Unit testing tools are used to check the functionality of individual
modules and to make sure that all independent modules works as expected. For example,
Jenkins, PHPUnit, JUnit, etc.
Mobile Testing Tools : Mobile testing tools are used to test the application for compatibility
on different mobile devices. For example, Appium, Robotium, Test IO,etc.
GUI Testing Tools : GUI testing tools are used to test the graphical user interface ofthe
software. For example, EggPlant, Squish, AutoIT, etc.
Bug Tracking Tools : Bug tracking tool helps to keep track of various bugs that come up
during the application lifecycle management. It helps to monitor and log all the bugs that
are detected during software testing. For example, Trello, JIRA, GitHub, etc.

SNPITRC 13
230493131036 Software Engineering

PRACTICAL: 9

AIM: Prepare SRS document for your System.

Software requirement specification (SRS):

Software requirement specification (SRS) is a complete document or description of the
requirements of a system or software application. In other words, “SRS is a document that
describes what the features of the software will be and what its behaviour will be, i.e.
how it will perform.” The advantage of SRS is that it takes less time and effort for
developers to develop software. What SRS is is like the layout of the software which the
user can review and see whether it (SRS) is made according to his needs or not. We learned
about software requirement specification, what it is, now let us read its features.

 Introduction:

 Purpose of this Document – At first, main aim of why this document is necessary and
what’s purpose of document is explained and described.
 Scope of this document – In this, overall working and main objective of document and
what value it will provide to customer is described and explained. It also includes a
description of development cost and time required.
 Overview – In this, description of product is explained. It’s simply summary or overall
review of product.

Functional Requirements:
In this, possible outcome of software system which includes effects due to operation of
program is fully explained. All functional requirements which may include calculations, data
processing, etc. are placed in a ranked order. Functional requirements specify the expected
behavior of the system-which outputs should be produced from the given inputs. They
describe the relationship between the input and output of the system. For each functional
requirement, detailed description all the data inputs and their source, the units of measure,
and the range of valid inputs must be specified.

Interface Requirements:
In this, software interfaces which mean how software program communicates with each other
or users either in form of any language, code, or message are fully described and explained.
Examples can be shared memory, data streams, etc.

Performance Requirements:
In this, how a software system performs desired functions under specific condition is
explained. It also explains required time, required memory, maximum error rate, etc. The
performance requirements part of an SRS specifies the performance constraints on the
software system. All the requirements relating to the performance characteristics of the

SNPITRC 14
230493131036 Software Engineering

system must be clearly specified. There are two types of performance requirements: static
and dynamic. Static requirements are those that do not impose constraint on the execution
characteristics of the system. Dynamic requirements specify constraints on the execution
behaviour of the system.

Design Constraints:
In this, constraints which simply means limitation or restriction are specified and explained
for design team. Examples may include use of a particular algorithm, hardware and software
limitations, etc. There are a number of factors in the client’s environment that may restrict
the choices of a designer leading to design constraints such factors include standards that
must be followed resource limits, operating environment, reliability and security
requirements and policies that may have an impact on the design of the system. An SRS
should identify and specify all such constraints.

Uses of SRS document:

 Development team require it for developing product according to the need.

 Test plans are generated by testing group based on the describe external behaviour.
 Maintenance and support staff need it to understand what the software product is
supposed to do.
 Project manager base their plans and estimates of schedule, effort and resources on it.
 customer rely on it to know that product they can expect.
 As a contract between developer and customer.
 in documentation purpose.

SNPITRC 15
230493131036 Software Engineering

Characteristics of Software Requirements Specification (SRS):

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS.
SRS is said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements: All
essential requirements, whether relating to functionality, performance, design, constraints,
attributes, or external interfaces.Definition of their responses of the software to all realizable
classes of input data in all available categories of situations. Full labels and references to all
figures, tables, and diagrams in the SRS and definitions of all terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. There are three types of possible conflict in the SRS:The specified
characteristics of real-world objects may conflicts. For example,The format of an output report
may be described in one requirement as tabular but in another as textual One condition may
state that all lights shall be green while another states that all lights shall be blue.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a method
used with multiple definitions, the requirements report should determine the implications in
the SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and stability if
each requirement in it has an identifier to indicate either the significance or stability of that
particular requirement. Typically, all requirements are not equally important. Some
prerequisites may be essential, especially for life-critical applications, while others may be
desirable. Each element should be identified to make these differences clear and explicit.
Another way to rank requirements is to distinguish classes of items as essential, conditional,
and optional.

SNPITRC 16
230493131036 Software Engineering

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly
obtain changes to the system to some extent. Modifications should be perfectly indexed and
cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each condition in future development or enhancement
documentation.

9. Design Independence: There should be an option to select from multiple design alternatives
for the final system. More specifically, the SRS should not contain any implementation details.

10. Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit domain
but might not be trained in computer science. Hence, the purpose of formal notations and
symbols should be avoided too as much extent as possible. The language should be kept simple
and clear.

12. The right level of abstraction: If the SRS is written for the requirements stage, the details
should be explained explicitly. Whereas,for a feasibility study, fewer analysis can be used.
Hence, the level of abstraction modifies according to the objective of the SRS.

 Advantages of having a good Software Requirements Specification (SRS)

document include:

1. Improved communication and understanding between stakeholders and developers, as

the SRS clearly defines the requirements for the software system
2. Increased efficiency in the software development process, as a well-written SRS can
help to reduce the need for rework and change requests
3. Improved quality of the final software system, as a well-written SRS helps to ensure
that all requirements are met
4. Increased stakeholder satisfaction, as a well-written SRS helps to ensure that the
software system meets the needs of the business and its users
5. Improved traceability and verifiability, as a well-written SRS can be traced to other
documents and artifacts and its requirements can be tested and validated.
6. Clarity and Completeness: A good SRS document provides clear and complete
specifications for the software project, which ensures that all stakeholders have a
common understanding of the requirements and objectives.
7. Traceability: A good SRS document includes detailed requirements and specifications,
which enables traceability throughout the software development process.

SNPITRC 17
230493131036 Software Engineering

8. Testability: A good SRS document can serve as a basis for test cases and verification,
which can ensure that the software meets the requirements and specifications.
9. Improved Communication: A good SRS document can serve as a communication tool
between different stakeholders, such as project managers, developers, testers, and
customers.
10. Reduced Rework: A good SRS document can help to identify and resolve issues early in
the development process, which can reduce the need for rework and improve the overall
quality of the software.

 Disadvantages of having a poorly written SRS include:

1. Confusion and misunderstandings between stakeholders and developers, as the

requirements are not clearly defined or are vague
Increased rework and change requests, as the SRS does not accurately capture the
requirements of the software system
2. Reduced quality of the final software system, as a poorly written SRS can result in
requirements being missed or not fully met
3. Reduced stakeholder satisfaction, as a poorly written SRS does not accurately capture
the needs of the business and its users
4. Reduced traceability and verifiability, as a poorly written SRS can’t be traced to other
documents and artifacts and its requirements can’t be tested and validated.
5. It is important to note that, regardless of the quality of the SRS, gathering and
validating requirements is an iterative process, that should be continuously reviewed
and updated throughout the software development process.
6. Time-consuming: Creating a good SRS document can be a time-consuming process,
especially for complex software projects, which can delay the development process.
7. Changes and Updates: Changes or updates to the SRS document can cause delays in the
software development process and can be difficult to manage.
8. Lack of Flexibility: A detailed SRS document can restrict the flexibility of the
development process, which can be challenging for projects that require agile
development methodologies.
9. Limited Stakeholder Involvement: The process of creating an SRS document can limit
the involvement of stakeholders in the software development process, which can lead to
a lack of collaboration and input from different perspectives.
10. Ambiguity: A poorly written SRS document can lead to ambiguity and
misunderstandings, which can cause issues throughout the software development
process.

SNPITRC 18