LAB MANUAL

OF
SOFTWARE
ENGINEERING
(CIC-357)

Department of Information Technology

Maharaja Agrasen Institute of Technology, PSP area,
Sector-22, Rohini, New Delhi -110086
(Guru Gobind Singh Indraprastha University, New Delhi)
 MAHARAJA AGRASEN INSTITUTE OF TECHNOLOGY

VISION OF THE INSTITUTE

To attain global excellence through education, innovation, research, and work ethics with the
commitment to serve humanity.

MISSION OF THE INSTITUTE

M1. To promote diversification by adopting advancement in science, technology,

management, and allied discipline through continuous learning
M2. To foster moral values in students and equip them for developing sustainable
solutions to serve both national and global needs in society and industry.
M3. To digitize educational resources and process for enhanced teaching and effective
learning.
M4. To cultivate an environment supporting incubation, product development,
technology transfer, capacity building and entrepreneurship.
M5. To encourage faculty-student networking with alumni, industry, institutions, and
other stakeholders for collective engagement.
 MAHARAJA AGRASEN INSTITUTE OF TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY

VISION OF THE DEPARTMENT

To establish a center of excellence promoting Information Technology related education and

research for preparing technocrats and entrepreneurs with ethical values.

MISSION OF THE DEPARTMENT

M1. To excel in the field by imparting quality education and skills for software
development and applications.
M2. To establish a conducive environment that promotes intellectual growth and
research.
M3. To facilitate students to acquire entrepreneurial skills for innovation and product
development.
M4. To encourage students to participate in competitive events and industry interaction
with a focus on continuous learning.
 MAHARAJA AGRASEN INSTITUTE OF TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY

PROGRAM OUTCOMES (POs)
PO1 Engineering knowledge: Apply the knowledge of mathematics, science, engineering
fundamentals, and an engineering specialization to the solution of complex engineering
problems.
PO2 Problem analysis: Identify, formulate, review research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and engineering sciences.
PO3 Design/development of solutions: Design solutions for complex engineering problems
and design system components or processes that meet the specified needs with
appropriate consideration for the public health and safety, and the cultural, societal, and
environmental considerations.
PO4 Conduct investigations of complex problems: Use research-based knowledge and
research methods including design of experiments, analysis and interpretation of data,
and synthesis of the information to provide valid conclusions.
PO5 Modern tool usage: Create, select, and apply appropriate techniques, resources, and
modern engineering and IT tools including prediction and modeling to complex
engineering activities with an understanding of the limitations.
PO6 The engineer and society: Apply reasoning informed by the contextual knowledge to
assess societal, health, safety, legal and cultural issues and the consequent
responsibilities relevant to the professional engineering practice.
PO7 Environment and sustainability: Understand the impact of the professional
engineering solutions in societal and environmental contexts, and demonstrate the
knowledge of, and need for sustainable development.
PO8 Ethics: Apply ethical principles and commit to professional ethics and responsibilities
and norms of the engineering practice.
PO9 Individual and team work: Function effectively as an individual, and as a member or
leader in diverse teams, and in multidisciplinary settings.
PO10 Communication: Communicate effectively on complex engineering activities with the
engineering community and with society at large, such as, being able to comprehend and
write effective reports and design documentation, make effective presentations, and give
and receive clear instructions.
PO11 Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one’s own work, as a
member and leader in a team, to manage projects and in multidisciplinary environments.
PO12 Life-long learning: Recognize the need for, and have the preparation and ability to
engage in independent and life-long learning in the broadest context of technological
change.
 MAHARAJA AGRASEN INSTITUTE OF TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY

PROGRAM EDUCATIONAL OBJECTIVES (PEOs)

PEO1. The graduates would utilize their professional skills in Information Technology
to address real-world and societal challenges.

PEO2. The graduates would become successful entrepreneurs and motivators.

PEO3. The graduates would pursue research globally and engage in producing novel
products to serve humanity.

PEO4. The graduates would exhibit collaborative abilities with adherence to

professional ethics.
 MAHARAJA AGRASEN INSTITUTE OF TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY

PROGRAM SPECIFIC OUTCOMES (PSOs)

PSO1. Students are equipped with programming technologies applied in the

industry.

PSO2. Students are able to provide efficient solutions for emerging challenges in
the computation domain such as Artificial Intelligence, Data Science, Web
Technologies.

PSO3. Students are able to apply domain knowledge and expertise in the field of
Information Technology for enhancing research capability to transform
innovative ideas into reality.
CO OF THE LAB SUBJECT AND ITS MAPPING
WITH PO AND PSO

CO Course Outcome
CO1 Ability to have an understanding of SDLC Models, Techniques for Requirement
Elicitation, and SRS
Document.
CO2 To be able to explain Software Project Planning and various methods for
software design
CO3 To Understand Software Metrics, Software Reliability, and Quality assurance
CO4 Ability to have an understanding of Software testing, documentation and
maintenance.

CO & PO Mapping:

CO PO PO PO PO PO PO PO PO PO PO1 PO1 PO1

1 2 3 4 5 6 7 8 9 0 1 2

CO
1 3 2 2 2 3 - - - 3 2 2 3

CO
2 3 2 2 2 3 - - - 3 2 2 3

CO 3 2 2 2 3 - - _ 3 2 2 3
3

CO 3 2 2 2 3 - - - 3 2 2 3
4

CO & PSO Mapping

CO PSO1 PSO2 PSO3

CO1 2 3 3
CO2 3 2 2
CO3 3 3 3
CO4 2 2 2
 RUBRICS EVALUATION
0 1 2 3
Rubrics/ Marks Needs
Missing Inadequate Adequate
Improvement
There are minor The problem to be
omissions or solved is clearly
Is able to identify Problem is vaguely
No mention is vague details. stated. Objectives
the problem to be identified and
made of the Objectives are are complete,
R1 solved and define objectives are not
problem to be conceptually specific, concise,
the objective of relevant or
solved. correct and and measurable.
the experiment. erroneous.
measurable but
incomplete.
The experiment The experiment
The experiment is solves the problem
attempts to solve
The experiment designed to solve and has generic
Is able to design a the problem but
does not solve the the problem but
reliable needs logic applicable to
problem. contains missing generic data.
R2 experiment that improvement to
links. Solution is
solves the correctly arrive at Solution is fully
Solution is not attempted but
problem. it. Solution is implemented.
implemented at all. implementation is
partially
not correct.
implemented.
Diagrams and/or Diagrams and/or
Is able to Diagrams are
experimental experimental
communicate the missing and/or Diagrams are
procedures are procedures are
details of an experimental present but do not
R3 present but with clear and
experimental procedure is properly describe
errors that may complete.
procedure clearly missing or the procedure.
result in invalid
and completely. extremely vague.
conclusion.
All-important data All important data
Is able to record
Data are either Some important data are present, but are present,
and represent
R4 absent or are absent or recorded in an organized and
data in a
incomprehensible. incomprehensible. incomprehensible recorded clearly.
meaningful way.
way.
An acceptable An acceptable
Is able to make a No discussion is A judgment is made judgment is made judgment is made
judgment about presented about the about the results, but about the result, about the result,
R5 results of the is not reasonable or but the reasoning with valid
the results of the
experiment. experiment. coherent. is flawed or conclusions.
incomplete.
 CONTENTS
Page No.

Introduction of Lab Subject 1

Hardware & Software Requirement 2
List of Practical (As Per syllabus prescribed by 3
G.G.S.I.P.U)

List of Practical (Beyond the syllabus Prescribed by 5

G.G.S.I.P.U)

Format of the lab record to be prepared by the students 6

Marking scheme for the practical exam 7-11

For each Practical (Steps to be followed & Viva

12-83
Question).
 INTRODUCTION TO SOFTWARE
ENGINEERING LAB

Lab Objective:

The Software Engineering Lab has been developed to impart state-of-the-

art knowledge on Software Engineering practical aspects and UML in an
interactive manner. This course also provide scope to students where they
can solve small, real-life problems and present case studies, can further
demonstrate practical applications of different concepts.
Course Outcomes

At the end of the course, a student will be able to:

1. Ability to have an understanding of SDLC Models, Techniques for

Requirement Elicitation, and SRS Document.

2. To be able to explain Software Project Planning and various methods for software
design.

3. To understand Software Metrics, Software Reliability, and Quality assurance.

4. Ability to have an understanding of software testing, documentation and maintenance.

1
HARDWARE & SOFTWARE REQUIREMENT

CPU : Intel core i5

8GB RAM
1 TB HDD
Keyboard
Mouse
TFT

Printer : Laser Jet Printer

Software : STAR UML

2
 LIST OF PRACTICALS (AS PER SYLLABUS
PRESCRIBED BY G.G.S.I.P.U)
1. Write down the problem statement for a suggested system of
relevance.
2. Do requirement analysis and develop Software Requirement
Specification Sheet (SRS) for suggested system.
3. To perform the function-oriented diagram: Data Flow Diagram
(DFD) and Structured chart.
4. Draw the entity relationship diagram for the suggested system.
5. To perform the user’s view analysis for the suggested
system: Use case diagram.
6. To draw the structural view diagram for the system: Class diagram,
object diagram.
7. To draw the behavioral view diagram: State-chart diagram,
Activity diagram
8. To perform the behavioral view diagram for the suggested system:
Sequence diagram, Collaboration diagram
9. To perform the implementation view diagram: Component
diagram for the system.
10. To perform the environmental view diagram: Deployment
diagram for the system.
11. To perform various testing using the testing tool unit testing,
integration testing for a sample code of the suggested system.
12. To Perform Estimation of effort using FP Estimation for chosen
system.
13. To Prepare time line chart/Gantt Chart/PERT Chart for selected
software project.

Choose any one project and do the above exercises for that project

(a) Student Result Management System

3
(b) Library management system
(c) Inventory control system
(d) Accounting system
(e) Fast food billing system
(f) Blood bank system
(g) Railway reservation system
(h) Automatic teller machine
(i) Video library management system
(j) Hotel management system
(k) Hostel management system
(l) E-ticking
(m) Share online trading
(n) Hostel management system
(o) Resource management system
(p) Court case management system
(q) Bank Loan System

4
 LIST OF PRACTICALS (BEYOND THE
LIST PRESCRIBED BY G.G.S.I.P.U)
a.
1. To design a flow chart for chosen system.
2. To draw ER Diagram for chosen system.

5
 FORMAT OF THE LAB RECORDS TO BE
PREPARED BY THE STUDENTS
The students are required to maintain the lab records as per the
instruction:
1. All the record files should have a cover page as per the format.
2. All the record files should have an index as per the format.
3. All the record should have the following:
I. Date
II. Aim
III. Algorithm or The Procedure to be followed
IV. Program
V. Output
VI. Viva Questions

6
 MARKING SCHEME
FOR THE
PRACTICAL EXAMINATION

There will be two practical exams in each semester.

1. Internal Practical Exam
2. External Practical Exam

INTERNAL PRACTICAL EXAMINATION

It is taken by the concerned faculty of the batch.
MARKING SCHEME FOR INTERNAL EXAM IS:
Total Marks: 40
Division of 40 Marks is as follows:

1. Regularity/ Attendance
2. File
3. Quiz
4. Viva Voce

7
EXTERNAL PRACTICAL EXAMINATION
It is taken by the concerned faculty of the batch and by an external
examiner. In this exam, student needs to perform the experiment allotted
at the time of the examination, a sheet will be given to the student in
which some details asked by the examiner needs to be written and at the
last viva will be taken by external examiner.

MARKING SCHEME FOR THIS EXAM IS:

Total Marks : 60

Division of 60 marks is as follows

1. Sheet filled by the student : 15
2. Viva Voce : 20
3. Experiment performance : 15
4. File submitted : 10
NOTE:
● Internal marks + External marks = Total marks given to the
students
▪ (40 marks) (60 marks) (100 marks)

8
 ANNEXURE I
COVER PAGE OF THE LAB RECORD TO BE
PREPARED BY THE STUDENTS
SOFTWARE ENGINEERING LAB
CIC-357
(Size 20”, italics bold, Times New Roman)

Faculty Name:
(16”, Times New Roman) Student Name:
Roll No.:
Semester:
Batch:
(16”, Times New Roman)

Department of Information Technology

Maharaja Agrasen Institute of Technology, PSP area,
Sector-22, Rohini, New Delhi -110085
(18” bold Times New Roman)

9
 ANNEXURE II
FORMAT OF THE INDEX TO BE PREPARED BY THE
STUDENTS
SOFTWARE ENGINEERING LAB
PRACTICAL RECORD
PAPER CODE : CIC -357
Name of the student :
University Roll No. :
Branch :
Section/ Group :
PRACTICAL DETAILS
a) Experiments according to the list provided by GGSIPU
b)
Experiment Date Experiment Name Marks (0-3) Total Signature
No. Marks
(15)
R1 R2 R3 R4 R5
1.

2.

3.

4.

5.

10
 c) Experiments beyond the list provided by GGSIPU

Experiment Date Experiment Name Marks (0-3) Total Signature

No. Marks(15)
R1 R2 R3 R4 R5
1.

2.

3.

4.

5.

11
 INTRODUCTION OF SOFTWARE ENGINEERING LAB

INTRODUCTION TO STAR UML

StarUML is an open-source software modeling tool that supports UML (Unified Modeling
Language). It is based on UML version 1.4, provides eleven different types of diagrams and it
accepts UML 2.0 notation. It actively supports the MDA (Model Driven Architecture) approach
by supporting the UML profile concept and allowing to generate code for multiple languages.

Features

When you start a new project, StarUML proposes which approach you want to use: 4+1
(Krutchen), Rational, UML components (from Chessman and Daniels book), default or empty.
Depending on the approach, profiles and/or frameworks may be included and loaded. If you don't
follow a specific approach, the "empty" choice could be used. Although a project can be managed
as one file, it may be convenient to divide it into many units and manage them separately if many
developers are working on it together.

StarUML makes a clear conceptual distinction between models, views and diagrams. A Model is
an element that contains information for a software model. A View is a visual expression of the
information contained in a model, and a Diagram is a collection of view elements that represent
the user’s specific design thoughts.

StarUML is build as a modular and open tool. It provides frameworks for extending the
functionality of the tool. It is designed to allow access to all functions of the model/meta-model
and tool through COM Automation, and it provides extension of menu and option items. Also,
users can create their own approaches and frameworks according to their methodologies. The tool
can also be integrated with any external tools.

12
 The user interface is intuitive. On the upper right side, a window allows to rapidly navigate
between all the content of a project, adopting either a model or a diagram view. Multiple diagrams
can be open at the same time and tabs allow switching rapidly between views. The lower right
window allows to document the current diagram, either with plain text or attaching an external
document. During diagram editing, "wizards" are located around the object that give you the quick
shortcuts to main associated tasks with your current operation, like adding an attribute when you
create a class for instance. A right-click on the mouse brings the full set of operations at your
disposal.

StarUML has also a model verification feature. You can export diagram in different formats (jpg,
bmp, wmf). It also supports a patterns approach and import of Rational Rose files.

StarUML Generator is platform module to generate various artifacts (like as Microsoft Word,
Excel, PowerPoint, and Text-based artifacts) by templates depending on UML model elements in
StarUML. The users can define their own templates and can apply many different kinds of
templates to the same UML model, so the users can get various artifacts automatically, easily and
fast. The tool supports code generation and reverse engineering for Java, C# and C++.
So, we can summarize the key features of StarUML as follows: -

The key features of StarUML are:

 Multi-platform support (MacOS, Windows and Linux)

 UML 2.x standard compliant
 SysML support
 Entity-Relationship diagram (ERD)
 Data-flow diagram (DFD)
 Flowchart diagram
 Multiple windows
 Modern UX
 Dark and light themes
 Retina (High-DPI) display support
 MacPro Pro's Touch Bar support
 Model-driven development
 Open APIs
 Various third-party extensions
 Asynchronous model validation
 Export to HTML docs
 Automatic updates.

13
 EXPERIMENT 1
AIM:
Write down the problem statement for a suggested system of relevance.

THEORY:
The problem statement is the initial starting point for a project. It is basically a one to three-
page statement that everyone on the project agrees with that describes what will be done at a
high level. The problem statement is intended for a broad audience and should be written in
non-technical terms. It helps the non-technical and technical personnel communicate by
providing a description of a problem. It doesn't describe the solution to the problem.

The input to requirement engineering is the problem statement prepared by customer.

It may give an overview of the existing system along with broad expectations from the new
system.
The first phase of requirements engineering begins with requirements elicitation i.e. gathering of
information about requirements. Here, requirements are identified with the help of customer and
existing system processes. So, from here begins the preparation of problem statement.

So, basically a problem statement describes what needs to be done without describing how.

Performance Instruction:
1. Choose any one project from given list.
2. Collect all requirements
3. Identify functionalities
4. Write a one to three-page statement that everyone on the project agrees with that
describes what will be done at a high level.

Sample Output:
PROBLEM STATEMENT FOR RAILWAY RESERVATION SYSTEM
Software has to be developed for automating the manual railway reservation system. The system
should be distributed in nature. It should be designed to provide the functionalities as follows:
Reserve Seat: A traveler should be able to reserve seats in the desired train. A reservation form is to be filled
by the traveler and given to the clerk, who then checks for the availabilityof seats for the specified train and
date of journey. If seats are available, then entries are madeinto the system regarding the train name, train
number, date of journey, boarding station, destination, person name, age, sex and the total fare. Traveler is
asked to pay the required fareand the tickets are printed. It should be noted that a single ticket should not
reserve more thansix persons at a time and the children below 12 years and the senior citizens should get 50%
concession in their respective fare. If the seats are not available, then reservation request is rejected and the
Traveler is informed so.
14
1. Cancel Reservation: A traveler wishing to cancel a reservation is required to fill a form. The
traveler then submits the form and the ticket to the clerk. The clerk then deletes the
corresponding entries in the system and changes the reservation status of that train. The ticket
is crossed by hand and considered cancelled. A new cancellation ticket is generated and given
to the traveler along with the fare minus the 20% cancellation fees per reservation.
2. Update Train Information: Only the administrator can enter any changes related to the train
information like change in train name, train number, train route, etc. in the system.
3. Report Generation: Provision for generation of different reports should be there in the
system. The system should be able to generate reservation chart, monthly train report etc.
4. Login: For security reasons all the users of the systems are given a user ID and password.
Only when both the entries are correct and they match the user should be allowed to enter the
system.
5. View Reservation status: All the users should be able to see arrival & departure time and
reservation status of a train online. The user needs to enter the train number the PNR number
printed on the ticket so that the system can display the current train position like on time, late
by specified hours or the reservation status like confirmed, wait listed and RAC.
6. View Train Schedule: Provision should be made in the system to see information related to
the train schedules for entire train network. The user should be able to see the train name, train
number, boarding and destination stations, duration of journey etc.

Conclusion: The problem statement was written successfully by following the steps described
above.

15
VIVA - QUESTIONS:
Q-1. What is problem statement?

Q-2. What are the benefits of writing problem statement

Q-3. Writing a problem statement, is really a beneficial for you in proceeding proje

Q-4. Explain 5W’s can be used to spark the problem?

Q-5. What are steps that need to follow while writing problem statement?

16
 EXPERIMENT 2
AIM:
Do requirement analysis and develop Software Requirement Specification Sheet (SRS) for
suggested system.

THEORY:
Software Requirement Specification (SRS) is a document that describes the requirements of
a computer system from the user's point of view.
An SRS document specifies: The required behavior of a system in terms of: input data, required
processing, output data, operational scenarios and interfaces. The attributes of a system
including: performance, security, maintainability, reliability, availability, safety requirements
and design constraints.

A well-designed, well-written SRS accomplishes four major goals:

 It provides feedback to the customer. An SRS is the customer's assurance that the
development organization understands the issues or problems to be solved and the software
behavior necessary to address those problems. Therefore, the SRS should be written in
natural language (versus a formal language, explained later in this article), in an
unambiguous manner that may also include charts, tables, data flow diagrams, decision
tables, and so on.
 It decomposes the problem into component parts. The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the
problem, solidifies ideas, and helps break down the problem into its component parts in an
orderly fashion.
 It serves as an input to the design specification. As mentioned previously, the SRS serves
as the parent document to subsequent documents, such as the software design specification
and statement of work. Therefore, the SRS must contain sufficient detail in the functional
system requirements so that a design solution can be devised.
 It serves as a product validation check. The SRS also serves as the parent document for
testing and validation strategies that will be applied to the requirements for verification.

SRSs are typically developed during the first stages of "Requirements Development," which is
the initial product development phase in which information is gathered about what
requirements are needed--and not. This information-gathering stage can include onsite visits,
questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or
needs analysis of the customer or client's current business environment. The actual
specification, then, is written after the requirements have been gathered and analyzed.

Performance Instruction: SRS DOCUMENT TEMPLATE

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbrevations

17
 1.4 References
1.5 Overview

2. Overall Description
2.1 Product Perspective

2.1.1 System Interfaces

2.1.2 User Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and dependencies
2.6 Apportioning of requirements

3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
Login Screen
Train Info Parameters Screen
Train Information Screen
Passenger Info Parameters Screen
Passenger Information Screen
Passenger’s Train Choice Parameters Screen
Passenger Entry Info Screen
Non-Availability Info Screen
Passenger Entry Screen
Passenger Parameters Screen
Passenger List Report Parameters
RAC List Parameters Screen

3.1.2. Hardware Interfaces

18
 3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Software Product Features
3.2.1 Train Information Maintenance
Description
Validity Checks
Sequencing Information
Error Handling/ Response to Abnormal Situations
3.2.2 Passenger Information Maintenance
Description
Validity Checks
Sequencing Information
Error Handling/ Response to Abnormal Situations
3.2.3 Ticket Generation
Description
Validity Checks
Sequencing Information
Error Handling/ Response to Abnormal Situations
3.2.4 Repot Generation
Passenger List and RAC Report
WL Report
Monthly Passenger List Report
3.2.5 User Accounts Information Maintenance
Description
Validity Checks

Sequencing Information

Error Handling/ Response to Abnormal Situations

3.1.2. Hardware Interfaces

19
 3.1.5 Software Interfaces
3.1.6 Communications Interfaces
3.3 Software Product Features
3.3.1 Train Information Maintenance
Description
Validity Checks
Sequencing Information
Error Handling/ Response to Abnormal Situations
3.3.2 Passenger Information Maintenance
Description
Validity Checks
Sequencing Information
Error Handling/ Response to Abnormal Situations
3.3.3 Ticket Generation
Description
Validity Checks
Sequencing Information
Error Handling/ Response to Abnormal Situations
3.3.4 Repot Generation
Passenger List and RAC Report
WL Report
Monthly Passenger List Report

3.3.5 User Accounts Information Maintenance

Description
Validity Checks
Sequencing Information
Error Handling/ Response to Abnormal Situations
3.4 Performance Requirements
20
3.5 Design Constraints
3.6 Software System Attributes
3.6.1 Security
3.6.2 Maintainability
3.6.3 Portability
3.7 Logical Database Requirements
3.8 Other Requirements

Sample Output:

1. INTRODUCTION
This document aims at defining the overall software requirements for ‘RAILWAY
RESERVATION SYSTEM’. Efforts have been made to define the requirements exhaustively
and accurately. The final product will be having only features/functionalities mentioned in this
document and assumptions for any additional functionality/feature should not be made by any of
the parties involved in developing/testing/implementing/ using this product. In case it is required
to have some additional features a formal change request will need to be raised and subsequently
a new release of this document and/or product will be produced.

1.1 PURPOSE
This specification document describes the capabilities that will be provided by the software
application ‘RAILWAY RESERVATION SYSTEM’. It also sates the various required constraints
by which the system will abide. The intended audiences for this document are the development
team, testing team and end users of the product.

1.2 SCOPE
The software product ‘RAILWAY RESERVATION SYSTEM’ is an application that will be used
for ticketing, reservation, cancellation and management of railway system for our government.
The application will manage the information about various passengers which travel through the
railways, through which train they want to travel, where the want to travel, distance between the
two cities, what is the current status and the status of next three days of the reservation, what is the
fare, what is the class through they want to travel and their personal records. Printable tickets for
the passengers will also be generated.
This application will greatly simplify and speed up the result preparation and management process

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

The following abbreviation has been used throughout this document

21
PNR: Passenger Name Record
RAC: Reservation Against Cancellation.

WL: Waiting List.

1.3 REFERENCES
(i) Website: For more information, log on to www.indianrail.gov.in
1.4 OVERVIEW
The rest of this SRS document describes the various system requirements, interfaces, features and
functionalities in detail.

1. OVERALL DESCRIPTION

1.1 PRODUCT PERPECTIVE

The application will be a windows-based, self-contained and independent software product.

Front end client (wit

data entry/delete/ Backend
update/view and Database
reporting facility)

1.1.1 SYSTEM INTERFACES

None
1.1.2 USER INTERFACES
The application will have a user-friendly and menu based interface. Following screens will be
provided:
(i) A login screen for entering the username, password and role (Reservation Clerk,
Administrator, Coordinator) will be provided. Access to different screen will be based upon
the role of the user.
(ii) There will be a screen for capturing and displaying information regarding what trains are
scheduled during which date, how much is the fare, and what are the classes in the trains.
(iii) There will be a screen for displaying information regarding various passengers.
(iv) There will be a screen for capturing and displaying information regarding which passenger
is currently reserved in which train and what is the class of that seat.
(v) There will be a screen that will capture information regarding the discount in the fare of
the ticket. Discount will be given on various basis like senior citizen, student concession,
scheduled cast etc.
(vi) There will be a screen for capturing and displaying information regarding which all user
account exists in the system, thus showing who all can access the system.

The following reports will be generated:

22
 (i) Reservation Chart: Printable report will be generated to show the list of the passengers
reserved in a particular train along with the class of their travel.
(ii) RAC Chart: Printable report will be generated to show to show the list of passengers who
are getting their seats in RAC in a particular train.
(iii) Waiting List: Printable reports will be generated to show the list of the passengers who are
in the waiting list of the reservation for their seats in a particular train.
(iv) Monthly Report: Monthly report will be generated for the railway department to show how
many passengers have traveled during the particular month.

1.1.3 HARDWARE INTERFACES

(i) Screen resolution of at least 800x600-required for proper and complete viewing of screen.
Higher resolution would not be a problem.
(ii) Support for printer (dot –matrix /Desk Jet /inkjet etc. –any will do)-that is,
appropriatedrivers are installed and printer connected printers will be required for
printing of reports.
(iii) Standalone system or network based-not a concern, as it will be possible to run the
application on any of these.

1.1.4 SOFTWARE INTERFACES

(i) Any window -based operating system (window 95/98/2000/XP/NT).
(ii) MS access 2000 as the DBMS—for database. Future release of the application will aim at
upgrading to oracle 8i as the DBMS.
(iii) Crystal reports 8—for generating and viewing pay slips and discharge slips.
(iv) Visual Basic 6—for coding /developing the software.

Software mentioned in pts. (iii) and (iv) above will be required only for development of the application.
The final application will be packaged as an independent setup program that will be delivered to the
client (hospital in this case

1.1.5 COMMUNICATION INTERFACES

None

23
1.1.6 MEMORY CONSTRAINTS

At least 64 MB RAM and 2 GB space on hard disk will be required for running the program.

1.1.7 OPERATIONS
This product release will not cover any automated housekeeping aspects of the database. The DBA at
the client site (i.e., Railways) will be responsible for manually deleting old/non-required data.
Database backup and recovery will also have to be handled by the DBA. However, the system wil
provide a ‘RESET SYSTEM’ function that will delete (upon conformation from the administrator) all
the existing information from the database.
1.1.8 SITE ADAPTATION REQUIREMENTS
The terminals at client site will have to support the hardware and software interface specified in
above section.
1.2 PRODUCT FUNCTIONS
The system will allow access only to authorized users with specific roles. Depending upon the user’s
role he/she will be able to access only specific modules of the system.
A summary of the major functions that the software will perform:
(i) A LOGIN facility for enabling only authorized access to the system.
(ii) User (with role Reservation Clerk) will be able to add/modify/delete information about
different passengers that are reserving their ticket in different trains and dates.
(iii) User (with role Reservation Clerk) will be able to add/modify/delete information about
different seats that are offered in a train (1AC, 2AC, 3AC, Sleeper). The Reservation list
of passengers along with their class should be displayed.
(iv) User (with role Reservation Clerk) will be able to add/modify/delete information about the
waiting list of the passengers and their RAC.
(v) User (with role Reservation Clerk) will be able to print the ticket of the passenger.
(vi) User (with role Administrator) will be able to generate printable reports.
(vii) User (with role Administrator) will be able to ‘Reset’ the system – leading to deletion of
all existing information from the backend database.
(viii) User (with a role Administrator) will be able to create/ modify/ delete new/ existing user
accounts.

1.3 USER CHARACTERISTICS

(i) Educational Level- At least a graduate should be comfortable with English.

(ii) Experience- Should be well informed about the features concerning railways. Technical

24
 expertise-Should be comfortable with general purpose applications of computer.

(iii) Technical expertise-Should be comfortable with general purpose applications of computer.

1.4 CONSTRAINTS
(i) Since the DBMS being used in MS access 2000, which is not a very powerful DBMS it
will not be able to store a very huge number of records.
(ii) Due to limited features of DBMS being used performance tuning features will not be
applied to the queries and thus the system may become slow with the increase in the records
being stored.
(iii) Due to limited features of DBMS being used, database auditing will also not be provided.
(iv) Users at Railway Reservation will have to implement a security policy to safeguard the
passenger related information from being modified by unauthorized users (by means of
gaining access to the backend database).

1.5 ASSUMPTIONS AND DEPENDENCIES

The numbers of seats in a train are fixed. There should be no additions in the number of births.
1.6 APPORTIONING OF REQUIREMENTS
None.

2. SPECIFIC REQUIREMENTS

This section contains the software requirements to a level of detail sufficient to enable designers
to design the system, and testers to test that system.
2.1 EXTERNAL INTERFACE REQUIREMENTS
2.1.1 USER INTERFACES
The following screens will be provided:
Login Screen:
This will be the first screen that will be displayed. It will allow user to access different screens
based upon the user’s role. Various fields available on this screen will be:
(i) User ID: Alphanumeric of length upto 10 characters.
(ii) Password: Alphanumeric of length upto 8 characters.
(iii) Role: Will have the following values:
Administrator, Coordinator, Reservation Clerk.
Train Info Parameters Screen:
This screen will be accessible only to user with role Administrator. It will allow the user to enter
the name of train for which the user wants to access the train information.

25
Train Information Screen:

This screen will be accessible only to user with role Administrator. It will allow user to
add/modify/delete information about new/existing train(s) for a particular date that was selected in
the ‘Train Info Parameters’ screen. The list of available seats for that train will also be displayed.
Various fields available on this screen will be:
(i) Train number: of format T#### (# represent a digit).
(ii) Train Name: Alphanumeric of length upto 50 characters.
(iii) Seats: Number of total seats in each class section of the train.

Passenger Info Parameters Screen:

This screen will be accessible only to user with role Administrator. It will allow the user to enter
the train number for which the user wants to access the passenger information. Passenger
Information Screen:
This screen will be available only to role Administrator. It will allow the user to add/modify/delete
information about new/existing student(s) for a particular train number. Train wise list of
passengers will also be displayed. Various fields available on these screens will be:
(i) PNR number: of the format PNR########## (# represent Alphanumeric digits).
(ii) Passenger Name: will have only alphabetic letters and length upto 40 characters.
(iii) Sex: will have only one alphabet either ‘M’ or ‘F’.
(iv) Age: will have only three digits.
(v) Train number: of the format T#### (# represent a digit).

Passenger’s Train Choice Parameters Screen:

This screen will be accessible only to user with role Administrator. It will allow the user to enter
the train number and the class of the travel for which the user wants to access the passenger’s train
choice information.
Passenger’s Train Choice Information Screen:
This screen will be accessible only to user with role Administrator. It will allow the user to
add/modify/delete passenger’s choices for the trains selected in ‘Passenger’s Train Choice
Parameters’ screen. For the selected train it will display the list of seats available in the choices of
the passenger. The screen will display the list of passengers who have been allotted the seat. The
user will be able to view/add/modify/delete the passenger’s choice in the list.
Passenger Entry Info Screen:
This screen will be accessible only to user with role Reservation Clerk. It will allow the user to
enter the train number and the class of the train for which the user wants to access the passenger
information.

26
Non-Availability Info Screen:
This screen will be accessible to the user with the role Administrator. It will display the error
message to the user about the non-availability of the seats in the current train and class. It allows
user to enter another choice for the train number and class. It also allows the user if he wants to
continue reserving in the current train and class in the waiting section.

Passenger Entry Screen:

This screen will be accessible only to user with role Reservation Clerk. It will allow user to
add/modify/delete information about the seats reserved by different passengers who have been or
are going to be allotted seats in the train number and class selected in the ‘Passenger Entry Info’
screen. The screen will display the list of passengers currently who have been allocated the seats.
The user will be able to view/add/modify/delete the passenger information in the list. Various
fields available on this screen will be:
(i) PNR number: PNR number of all passengers in the current train.
(ii) Passenger Name: will display the name of passenger.
(iii) Sex: will display the sex of the passenger.
(iv) Age: will display the age of the passenger.
(v) Status: will display the status of the reservation i.e. whether the passenger has been
allotted the seat and its seat number or is in RAC or WL.Passenger Parameters
Screen:
This screen will be accessible only to user with role Reservation Clerk. It will allow the user to
enter the PNR number and the Train number of the passenger for whom the user wants to
view/print the ticket.
Passenger List Report Parameters:
This screen will be accessible only to user with role Coordinator. It will allow the user to enter the
train number for which the user wants to view/print the passenger list report.
RAC List Parameters Screen:
This screen will be accessible only to user with role Coordinator. It will allow the user to enter the
train number for which the user wants to view/print the RAC list report.
WL List Parameters Screen:
This screen will be accessible only to user with role Coordinator. It will allow the user to enter the
train number for which the user wants to view/print the WL report.
Monthly Passenger List Report Parameters:
This screen will be accessible only to user with role Coordinator. It will allow the user to enter the
month for which the user wants to view/print the passenger list report.

27
3.1.2 HARDWARE INTERFACES
As stated in section 2.1.3.

3.1.3 SOFTWARE INTERFACES

As stated in section 2.1.4.
3.1.4 COMMUNICATIONS INTERFACES
None.

2.2 SOFTWARE PRODUCT FEATURES

2.2.1 TRAIN INFORMATION MAINTENANCE
Description:
The system will maintain information about various trains being offered to the passengers. The
following information would be maintained for each train:
Train number, train name, train type (superfast, express, passenger, mail etc.), total seats, classes,
number of the station the train will pass through.
The system will allow creation/modification/deletion of new/existing trains.
Validity Checks:
(i) Only user with role Administrator will be authorized to access the Train information
Maintenance module.
(ii) Each compartment will have a maximum of 72 seats.
(iii) Each train will have atleast two classes.
(iv) Train number will be different for each train.
(v) Train number cannot be blank.
(vi) PNR number cannot be blank.
(vii) Train name cannot be blank.
(viii) Number of seats cannot be zero.

Sequencing Information:
Train info will have to be entered in the system before any info regarding passenger is entered.
Error Handling/ Response to Abnormal Situations:
If any of the above validations/ sequencing flow does not hold true, appropriate error msg. will be
prompted to user for doing the needful.

2.2.2 PASSENGER INFORMATION MAINTENANCE

Description:
28
The system will maintain information about various passengers allotted seats or are waiting to be
allotted seats in different trains. The following information would be maintained for each train:
Train number, PNR number, Class, Passenger Info.
The system will allow creation/modification/deletion of new/existing passengers and also have the
ability to list all the passengers allotted or are waiting to be allotted seats in a particular train.
Validity Checks:
(i) Only user with role Reservation Clerk will be authorized to access the Passenger
Information Maintenance module.
(ii) Every passenger will have a unique PNR number.
(iii) PNR number cannot be blank.
(iv) Passenger name cannot be blank.
(v) Train number cannot be blank.

Sequencing Information:
Train info will have to be entered in the system before any info regarding passenger is entered.
Error Handling/ Response to Abnormal Situations:
If any of the above validations/ sequencing flow does not hold true, appropriate error msg. will be
prompted to user for doing the needful.

2.2.3 TICKET GENERATION

Description:
The system will generate ticket for every passenger in different trains.
TICKET WILL HAVE THE FOLLOWING FORMAT:

INDIAN RAILWAYS
NAME OF TRAIN
TRAIN NUMBER

PNR NUMBER: NUMBER OF SEATS(s):

STATUS SEAT NO. NAME AGE SEX

29
STARTING STATION: DESTINATION:
DISTANCE IN kms: AMOUNT PAID (in figures):
AMOUNT PAID (in words): DATE OF JOURNEY: dd/m

SIGNATURE OF RAILWAY MINISTER

Validity Checks:
(i) Only User with role Coordinator will be authorized to access the Ticket Generation
module.
Sequencing Information:
Ticket for a particular passenger can be generated by the system only after PNR number has been
entered in the system for a given train number, the passenger info for that ticket has been entered
in the system, the choice for the train has been entered in the system, the journey date, and the
amount has been paid to the reservation clerk.
Error Handling/ Response to Abnormal Situations:
If any of the above validations/ sequencing flow does not hold true, appropriate error msg. will be
prompted to user for doing the needful.
2.2.4 REPORT GENERATION
Passenger List and RAC Report:
For each train a passenger list and a RAC list will be generated containing the list of passengers
who have been allotted seats in the train.

INDIAN RAILWAYS
NAME OF TRAIN
TRAIN NUMBER

COACH NO.:

30
 S. No. PNR NO. SEAT NO. NAME AGE SEX

WL Report:
For each train a WL will be generated containing the list of passengers who are waiting to get the
seats allotted in a train.

INDIAN RAILWAYS
NAME OF TRAIN
TRAIN NUMBER

S. No. PNR NO. WL NAME AGE SEX

STATUS

Monthly Passenger List Report:

For each month a passenger list will be generated containing the information about the number of
passengers traveling each day and through each train.

INDIAN RAILWAYS
MONTH/YEAR

S. No. DATE TRAIN NO. TRAIN NAME NO. OF PASSENGERS

TRAVELLED

2.2.5 USER ACCOUNTS INFORMATION MAINTENANCE

Description: The system will maintain information about various users who will be able to access

31
the system. The following information would be maintained:

User Name, User ID, Password, and Role.

Validity Checks:
(i) Only user with role Administrator will be authorized to access the User Accounts
Information Maintenance module.
(ii) User Name cannot be blank.
(iii) User ID cannot be blank.
(iv) User ID should be unique for every user.
(v) Password cannot be blank.
(vi) Role cannot be blank.

Sequencing Information:
User Account for particular user has to be created in order for the system to be accessible to that
user. AT system startup, only a default user account for ‘Administrator’ would be present in the
system.
Error Handling/ Response to Abnormal Situations:
If any of the above validations/ sequencing flow does not hold true, appropriate error msg. will be
prompted to user for doing the needful.

2.3 PERFORMANCE REQUIREMENTS

None
2.4 DESIGN CONSTRAINTS
None
2.5 SOFTWARE SYSTEM ATTRIBUTES
2.5.1 SECURITY
The application will be password protected. Users will have to enter correct username, password and
role in order to access the application.
2.5.2 MAINTAINABILITY
The application will be designed in a maintainable manner. It will be easy to incorporate new
requirements in the individual modules (i.e., new trains, new timings, fare hike).

32
2.5.3 PORTABILITY
The application will be easily portable on any windows-based system that has MS-Access 2000
installed.

2.6 LOGICAL DATABASE REQUIREMENTS

The following information will be placed in the database:
(i) Passenger Info.
(ii) PNR Number.
(iii) Destination.
(iv) Train Number.

2.7 OTHER REQUIREMENTS

None.

Conclusion: The SRS was written successfully by following the template described above.

VIVA - QUESTIONS:

Q-1. What are the objectives of requirement analysis?

Q-2. Define different types of requirements

Q-3. Outline structure of SRS Document?

Q-4. What are benefits of writing SRS document

Q-5. Define Functional and non-functional requirements

33
 EXPERIMENT 3.
AIM:
To perform the function-oriented diagram: Data Flow Diagram (DFD) and Structured chart.

THEORY:
Data flow diagrams are versatile diagramming tools. With only four symbols, data flow diagrams
can represent both physical and logical information systems. The four symbols used in DFD
representation are data flows, data stores, processes, and sources / sinks (or external entities).

Symbols of DFD:

34
Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.

Data Flow Diagram Layers

Draw data flow diagrams in several nested layers. A single process node on a high-level diagram
can be expanded to show a more detailed data flow diagram. Draw the context diagram first,
followed by various layers of data flow diagrams.

35
A Structure Chart (SC) in software engineering is a chart which shows the breakdown of a
system to its lowest manageable levels. They are used in structured programming to arrange
program modules into a tree. Each module is represented by a box, which contains the module's

name. The lines represent the connection and or ownership between activities and sub activities
as they are used in organization charts. The tree structure visualizes the relationships between
modules.

Performance Instruction:
To draw DFD
1) Identify various processes, data store, input, output etc. of the system and analyses it.
2) Use processes at various levels to draw the DFDs.
To draw structured Chart Diagram
3) Identify various modules, input, output etc. of the system.
4) Draw structured chart diagram describing it in form of levels.

Sample Output:

Context Diagram / Level 0 DFD

36
 Level 1 DFD

Structured Diagram

Conclusion: DFD and Structured Chart diagram was made successfully by following above
steps.

VIVA - QUESTIONS:

Q-1. Define DFD? What are different levels of DFD?

Q-2. Describe symbols used for constructing DFDs?

Q-3. Distinguish between a data flow diagram and a flow chart with example?

Q-4. Explain structured chart diagram?

Q-5. Describe symbols used for constructing structured chart diagram?

37
 EXPERIMENT 4.
AIM:
Draw the entity relationship diagram for the suggested system.

THEORY:
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities” such as people,
objects or concepts relate to each other within a system. ER Diagrams are most often used to design or
debug relational databases in the fields of software engineering, business information systems, education
and research. Also known as ERDs or ER Models, they use a defined set of symbols such as rectangles,
diamonds, ovals and connecting lines to depict the interconnectedness of entities, relationships and their
attributes.

When to use: ER diagrams are used to model and design relational databases, in terms of logic and
business rules (in a logical data model) and in terms of the specific technology to be implemented (in a
physical data model.)

Entity:

An entity may be any object, class, person or place. In the ER diagram, an entity can be represented as
rectangles.

Consider an organization as an example- manager, product, employee, department etc. can be taken as an
entity.

Weak Entity

An entity that depends on another entity called a weak entity. The weak entity doesn't contain any key attribute
of its own. The weak entity is represented by a double rectangle.

38
Attribute

The attribute is used to describe the property of an entity. Eclipse is used to represent an attribute.

For example, id, age, contact number, name, etc. can be attributes of a student.

Composite Attribute

An attribute that composed of many other attributes is known as a composite attribute. The composite attribute
is represented by an ellipse, and those ellipses are connected with an ellipse.

39
Multivalued Attribute

An attribute can have more than one value. These attributes are known as a multivalued attribute. The double
oval is used to represent multivalued attribute.

For example, a student can have more than one phone number.

Derived Attribute

An attribute that can be derived from another attribute is known as a derived attribute. It can be represented
by a dashed ellipse.

For example, A person's age changes over time and can be derived from another attribute like Date of birth.

40
Relationship

A relationship is used to describe the relation between entities. Diamond or rhombus is used to represent the
relationship.

Types of Relationships are: -

1. One to one relationship
2. One to many relationship
3. Many to many relationship
4. Many to one relationship

Sample Output

41
42
 EXPERIMENT 5
AIM:
To perform the user’s view analysis for the suggested system: Use case diagram.

THEORY:
The use-case diagram can provide the user’s view for designing of the software product. And it
can also be tested by matching up the requirements with the use-cases.
When to Use: Use Cases Diagrams
Use cases are used in almost every project. They are helpful in exposing requirements and planning
the project. During the initial stage of a project most use cases should be defined, but asthe project
continues more might become visible.
Actors---Are NOT part of the system – they represent anyone or anything that must interact with
the system.
Only input information to the system.
Only receive information from the system.
Both input to and receive information from the system.

Represented in UML as a stickman.

Use Case
A sequence of transactions performed by a system that yields a measurable result of values for a
particular actor
A use case typically represents a major piece of functionality that is complete from
beginning to end. A use case must deliver something of value to an actor

Use Case Relationships

Between actor and use case.
Association / Communication.
Arrow can be in either or both directions; arrow indicates who initiates communication.
Between use cases (generalization):
Uses: Where multiple use cases share pieces of same functionality.

43
Performance Instruction:
1) Identify various processes, use-cases, actors etc. of the system and analyze it.
2) Use processes at various levels and draw use case diagram.

Sample Output:

Use case Diagram

Conclusion: Use Case diagram was made successfully by following above steps.

44
VIVA - QUESTIONS:

Q-1. Explain use case approach of requirement elicitation

Q-2. Explain term: use-case, use-case scenarios, use-case diagrams?

Q-3. What are actors and use cases?

Q-4. Explain guidelines that should be kept in mind while creating use cases?

Q-5. Name the person who invented use case approach?

45
 EXPERIMENT 6
AIM:
To draw the structural view diagram for the system: Class diagram, object diagram.

THEORY:
Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements such
asclasses, packages and objects. Class diagrams describe three different perspectives when
designing a system, conceptual, specification, and implementation. Classes are composed of
three things: a name, attributes, and operations. Below is an example of a class:

Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams. Object diagrams represent an instance of a class diagram. The basic concepts are
similar for class diagrams and object diagrams. Object diagrams also represent the static view of
a system but this static view is a snapshot of the system at a particular moment.

Object diagrams are used to render a set of objects and their relationships as an instance.

Performance Instruction:
To draw class diagram
1) Identify various elements such as classes, member variables, member functions etc. of
the class diagram
2) Draw the class diagram as per the norms

To draw object diagram

1) First, analyze the system and decide which instances have important data and association.
2) Second, consider only those instances, which will cover the functionality.
3) Third, make some optimization as the number of instances are unlimited.

46
Sample Output:

Class diagram

47
 Object Diagram

Conclusion: Class diagram and Object diagram were made successfully by following above
steps.

VIVA - QUESTIONS:

Q-1. Explain class diagram?

Q-2. Explain symbols used in it?

Q-3. Explain four types of relationship used in class diagram?

Q-4. Explain terms classes, interfaces, collaborations and dependency

48
 EXPERIMENT 7

AIM:

To draw the behavioral view diagram: State-chart diagram, Activity diagram

THEORY:

State diagrams are used to describe the behavior of a system. State diagrams describe
all of the possible states of an object as events occur. Each diagram usually represents objects of
a single class and tracks the different states of its objects through the system.

State chart diagrams represent the behavior of entities capable of dynamic behavior by specifying
its response to the receipt of event instances.

Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to
state diagrams because activities are the state of doing something. The diagrams describe the state
of activities by showing the sequence of activities performed. Activity diagrams can show
activities that are conditional or parallel. Activity diagrams show the flow of activities through the
system. Diagrams are read from top to bottom and have branches and forks to describe conditions
and parallel activities. A fork is used when multiple activities are occurring at the same time. The
diagram below shows a fork after activity1. This indicates that both activity2 and activity3 are
occurring at the same time. After activity2 there is a branch. The branch describes what activities
will take place based on a set of conditions. All branches at some point are followed by a merge
to indicate the end of the conditional behavior started by that branch. After the merge all of the
parallel activities must be combined by a join before transitioning into the final activity state.

49
Performance Instruction:

To draw state chart diagram

1) Identify various elements states and their different transition of the state-chart diagram
2) Draw the state-chart diagram as per the norms.

To draw activity diagram

1) Identify various elements such as different activity their boundaries etc. of the activity
diagram
2) Draw the activity diagram as per the norm

50
Sample Output:

State Chart Diagram

51
Activity diagram for booking ticket

52
 Activity Diagram for cancel ticket

Conclusion: State Chart and Activity diagram were made successfully by following above
steps.

53
VIVA - QUESTIONS:

Q-1. How activity diagram explains behavioral view of system?

Q-2. Explain steps followed to construct activity diagram?

Q-3. How state chart diagram explains behavioral view of system?

Q-4. Explain steps followed to construct state chart diagram?’

Q-5. Explain symbols used to construct these diagrams?

54
 EXPERIMENT 8
AIM:
To perform the behavioral view diagram for the suggested system: Sequence diagram,
Collaboration diagram.

THEORY:
Sequence diagrams show potential interactions between objects in the system being defined.
Normally these are specified as part of a use case or use case flow and show how the use case
will be implemented in the system. They include:

#Objects - oblong boxes or actors at the top - either named or just shown as belonging
to a class, from, or to which messages are sent to other objects.

# Messages - solid lines for calls and dotted lines for data returns, showing the messages
that are sent between objects including the order of the messages which is from the
top to the bottom of the diagram.
#Object lifelines - dotted vertical lines showing the lifetime of the objects.
#Activation - the vertical oblong boxes on the object lifelines showing the thread of
control in a synchronous system.
Sequence diagrams show a detailed flow for a specific use case or even just part of a
specific use case. They are almost self-explanatory; they show the calls between the
different objects in their sequence and can show, at a detailed level, different calls to
different objects. A sequence diagram has two dimensions: The vertical dimension
shows the sequence of messages/calls in the time order that they occur; the horizontal
dimension shows the object instances to which the messages are sent.

Collaboration Diagram
They are the same as sequence diagrams but without a time axis:

 Their message arrows are numbered to show the sequence of message sending.
 They are less complex and less descriptive than sequence diagrams.
 These diagrams are very useful during design because you can figure out how objects
communicate with each other.
55
Performance Instruction:
To draw Sequence Diagram
1) Identify the class instances (objects) by putting each class instance inside a box.

2) If a class instance sends a message to another class instance, draw a line with an open arrowhead
pointing to the receiving class instance; place the name of the message/method above the line.
3) Optionally, for important messages, you can draw a dotted line with an arrowhead pointing back
to the originating class instance; label the return value above the dotted line.
To draw collaboration Diagram
1) By simply pressing combination of keys, we can design collaboration diagram from sequence
diagram.

Sample Output:

Sequence Diagram for booking ticket

56
 Sequence Diagram for cancel diagram

Collaboration Diagram for booking ticket

57
 Collaboration Diagram for cancel ticket

Conclusion: Sequence diagram and Collaboration Diagram were made successfully by

following above steps.

VIVA - QUESTIONS:

Q-1. Explain use of sequence diagram?

Q-2. Explain steps to draw sequence diagram?

Q-3. Explain need of collaboration diagram?

Q-4. Explain steps to draw collaboration diagram?

Q-5. Explain terms- entity objects, interface objects and control objects?

58
 EXPERIMENT 9
AIM:
To perform the implementation view diagram: Component diagram for the system.

THEORY:
A component diagram provides a physical view of the system. Its purpose is to show the
dependencies that the software has on the other software components (e.g., software libraries) in
the system. The diagram can be shown at a very high level, with just the large-grain components,
or it can be shown at the component package level. [Note: The phrase component package level
is a programming language-neutral way of referring to class container levels such as .NET's
namespaces (e.g., System. Web.UI) or Java's packages (e.g., java.util).

Basic Component Diagram Symbols and Notations

Component
A component is a logical unit block of the system, a slightly higher abstraction than classes. It is
represented as a rectangle with a smaller rectangle in the upper right corner with tabs or the
word written above the name of the component to help distinguish it from a class.

Interface
An interface (small circle or semi-circle on a stick) describes a group of operations used
(required) or created (provided) by components. A full circle represents an interface created or
provided by the component. A semi-circle represents a required interface, like a person's input.

59
Dependencies
Draw dependencies among components using dashed arrows.

Port
Ports are represented using a square along the edge of the system or a component. A port is often
used to help expose required and provided interfaces of a component.

Performance Instruction:
To Draw a Component Diagram
 Take stock of everything needed to implement the planned system. For example, for a
simple e-commerce system, you'll need components that describe products, orders, and
customer accounts.
 Create a visual for each of the components.
 Describe the organization and relationships between components using interfaces, ports,
and dependencies

Sample Output:

60
 Component Diagram

Conclusion: Component diagram was made successfully by following above steps.

VIVA - QUESTIONS:

Q-1. Explain term component diagram?

Q-2. Component diagram explains which view of system?

Q-3. Explain steps to draw component diagram?

Q-4. What is benefit of drawing component diagram?

Q-5. Explain symbols used to draw component diagram?

61
 EXPERIMENT 10
AIM:
To perform the environmental view diagram: Deployment diagram for the system.

THEORY:
The deployment diagram shows how a system will be physically deployed in the hardware
environment. Its purpose is to show where the different components of the system will physically
run and how they will communicate with each other. Since the diagram models the physical
runtime, a system's production staff will make considerable use of this diagram.
The notation in a deployment diagram includes the notation elements used in a component
diagram, with a couple of additions, including the concept of a node. A node represents either a
physical machine or a virtual machine node (e.g., a mainframe node). To model a node, simply
draw a three-dimensional cube with the name of the node at the top of the cube.
Performance Instruction:
To create a deployment diagram
1) Identify component
2) Add shapes
3) Connect Nodes
4) Form
Sample Output:

Deployment Diagram

Conclusion: Deployment diagram was made successfully by following above steps.

62
VIVA - QUESTIONS:

Q-1. What is deployment diagram

Q-2. Deployment diagram explains which view of system?
Q-3. Explain steps to draw deployment diagram?
Q-4. Explain symbols used to draw deployment diagram?
Q-5. What is benefit of drawing deployment diagram?

63
 Experiment 11
AIM:
To perform various testing using the testing tool unit testing, integration testing for a sample code
of the suggested system.

THEORY:
“Testing is the process of executing a program with the intent of finding errors.”
The purpose of software testing is
1. To demonstrate that the product performs each function intended.
2. To demonstrate that the internal operation of the product performs according to specification
and all internal components have been adequately exercised.
3. To increase our confidence in the proper functioning of the software.
4. To show the product is free from defect.
5. All of the above.

Unit Testing—Checks each coded module for the presence of bugs. Unit testing’s purpose is to
ensure that each as- built module behaves according to its specification defined during detailed
design.

Integration Testing ---Interconnects sets of previously tested modules to ensure that the sets
behave as well as they did as independently tested modules. Integration testing’s purpose is to
ensure that each as-built component behaves according to its specification defined during
preliminary design.

Performance Instruction:
Unit test planning—Generate plans and procedures to test each module independently and
thoroughly.
Integration Test Planning—Generate plans and procedures to effect orderly system integration.

Sample Problem Statement:

Consider a program for the determination of the nature of roots of a quadratic equation. Its input
is a triple of positive integers (say a,b,c) and values may be from interval [0,100]. The program
output may have one of the following words. [Not a quadratic equation; Real roots; Imaginary
roots; Equal roots] Design the boundary value test cases.

Sample Output:
Quadratic equation will be of type:
ax2+bx+c=0
Roots are real if (b2-4ac)>0
64
Roots are imaginary if (b2-4ac)

Roots are equal if (b2-4ac)=0 Equation is not quadratic if a=0 The boundary value test cases are
:

Test Case a b c Expected Output

1 0 50 50 Not Quadratic
2 1 50 50 Real Roots
3 50 50 50 Imaginary Roots
99 50 50 Imaginary Roots
4
5 100 50 50 Imaginary Roots
6 50 0 50 Imaginary Roots
7 50 1 50 Imaginary Roots
8 50 99 50 Imaginary Roots
9 50 100 50 Equal roots
10 50 50 0 Real Roots
11 50 50 1 Real roots
12 50 50 99 Imaginary Roots
13 50 50 100 Imaginary Roots

The robust test cases are:

Test case a b c Expected Output

1 -1 50 50 Invalid input`

2 0 50 50 Not quadratic equation

3 1 50 50 Real roots
4 50 50 50 Imaginary roots
5 99 50 50 Imaginary roots
6 100 50 50 Imaginary roots

7 101 50 50 Invalid input

8 50 -1 50 Invalid input
9 50 0 50 Imaginary roots
10 50 1 50 Imaginary roots

65
 11 50 99 50 Imaginary roots

12 50 100 50 Equal roots

13 50 101 50 Invalid input

14 50 50 -1 Invalid input

15 50 50 0 Real roots

16 50 50 1 Real roots
17 50 50 99 Imaginary roots
18 50 50 100 Imaginary roots
19 50 50 101 Invalid input

Conclusion: Test Cases for given code was made successfully.

VIVA - QUESTIONS:

Q-1. what is software testing?

Q-2. Explain terms unit testing and integration testing?

Q-3. Why should we test? Who should do the testing?

Q-4. Discuss limitation of testing?

Q-5. Explain term functional and structural testing?

66
 EXPERIMENT 12
AIM:
To Perform Estimation of effort using FP Estimation for chosen system.

THEORY:
A function point is a "unit of measurement" to express the amount of business functionality an
information system (as a product) provides to a user. Function points are used to compute a
functional size measurement (FSM) of software.
The principle of Albrecht’s function point analysis (FPA) is that a system is decomposed into
functional units.
1. Inputs: information entering the system
2. Outputs: information leaving the system
3. Enquiries: requests for instant access to information
4. Internal logical files: information held within the system
5. External interface files: information held by other system that is used by the system being
analyzed.
The FPA functional units are shown in figure given below:

The five functional units are divided in two categories:

(i) Data function types
 Internal Logical Files (ILF): A user identifiable group of logical related data or control
information maintained within the system.
 External Interface files (EIF): A user identifiable group of logically related data or control

67
 information referenced by the system, but maintained within another system. Thismeans
that EIF counted for one system, may be an ILF in another system.
(ii) Transactional function types
 External Input (EI): An EI processes data or control information that comes from outside
the system. The EI is an elementary process, which is the smallest unit of activity that is
meaningful to the end user in the business.
 External Output (EO): An EO is an elementary process that generate data or control
information to be sent outside the system.
 External Inquiry (EQ): An EQ is an elementary process that is made up to an input-output
combination that results in data retrieval.
Special features
 Function point approach is independent of the language, tools, or methodologies used for
implementation; i.e., they do not take into consideration programming languages, data
base management systems, processing hardware or any other data base technology.
 Function points can be estimated from requirement specification or design specification,
thus making it possible to estimate development efforts in early phases of development
 Function points are directly linked to the statement of requirements; any change of
requirements can easily be followed by a re-estimate.
 Function points are based on the system user’s external view of the system, non-technical
users of the software system have a better understanding of what function points are
measuring.

Performance Instruction:

68
1. Observe functional units and their weighting factors.
2. Compute them in formula to find value of UFP count.
3. Find value of FP by using formula.

Sample Problem Statement:

Consider a project with the following parameters.
(i)External Inputs:
(a) 10 with low complexity
(b) 15 with average complexity
(c) 17 with high complexity

(ii) External Outputs:

(a) 6 with low complexity

(b) 13 with high complexity

(iii) External Inquiries:

(a) 3 with low complexity

(b) 4 with average complexity
(c) 2 with high complexity

(iv) Internal logical files:

(a) 2 with average complexity

(b) 1 with high complexity

(v) External Interface files:

(a) 9 with low complexity

In addition to above, system requires

69
 i. Significant data communication
ii. Performance is very critical
iii. Designed code may be moderately reusable
iv System is not designed for multiple installation in different organizations.
Other complexity adjustment factors are treated as average. Compute the function points for the
project.

Sample Solution: Unadjusted function points may be counted using below table
Functional Units Count Complexity Complexity Functional Unit
Totals Totals
External Inputs 10 Low * 3 30
(EIs) 15 Average * 4 60
17 High * 6 102 192
External Outputs 6 Low * 4 24
(EOs) 0 Average * 5 0
13 High * 7 91 115
External 3 Low * 3 9
Inquiries (EQs) 4 Average * 4 16
2 High * 6 12 37
External logic 0 Low * 7 0
Files (ILFs) 2 Average * 10 20
1 High * 15 15 35
External 9 Low * 5 45
Interface Files 0 Average * 7 0
(EIFs) 0 High * 10 0 45
Total Unadjusted Function Point Count = 424

Σ Fi = 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41

CAF = (0.65 + 0.01* Σ Fi)

= (0.65 + 0.01* 41)
= 1.06
FP = UFP * CAF
= 424*1.06
= 449.44
Hence FP = 449

Conclusion: FP estimation was done successfully.

70
VIVA - QUESTIONS:

Q-1. Explain five functional units of functional point analysis (FPA)?

Q-2. Explain special features of FPA

Q-3. Explain three weighting factors of functional unit

Q-4. Explain term unadjusted function point count (UFP)?

Q-5. What are uses of function point?

71
 EXPERIMENT 13

AIM:

To Prepare time line chart/Gantt Chart/PERT Chart for selected software project. Description: A Gantt
chart is a graphical depiction for planning and scheduling projects. It breaks a project into smaller pieces of
tasks with each of these spread out over time. With it, you can see task dependencies, scheduling
constraints, duration of each task and percent complete.

In a Gantt Chart, each activity is represented by a bar; the position and length of the bar reflects

the start date, duration and end date of the activity. The milestone is represented by a triangle,

and the relationship is always shown with an arrow.

Gantt Chart

PERT stands for Program Evaluation Review Technique. It was introduced by the United

States Navy in the 1950s. Pert chart is also a project management tool used to plan tasks within aproject –
making it easier to schedule and coordinate team members accomplishing the work.

72
Pert chart was initially developed to simplify the planning and scheduling of large and complexprojects.
Pert chart looks like a flowchart. It uses boxes and arrows to show the subtasks and their dependencies.

PERT Chart

Performance Instruction:

To Create a Gantt Chart

1. Create a Task Table

List each task in your project in start date order from beginning to end. Include the task name,
start date, duration, and end date.
2. Build a Bar Chart
Click in the empty Series name: form field first, then click on the table cell that reads Start Date.

To Create a PERT Chart.

1. Create a Text Box.

73
2. With the text box still selected, go to the Format tab under Drawing Tools.
3. Click on the inside of the text box and begin entering any information for a single task.

Sample Output:

Gantt Chart

PERT Chart

Conclusion: Gantt chart and PERT chart were made successfully.

74
VIVA - QUESTIONS:

Q-1. Explain term Gantt chart?

Q-2. Explain term PERT chart?

Q-3. What is advantage of using PERT chart?

Q-4. What are advantages of using Gantt chart?

Q-5. What are limitations of Gantt chart?

75
 Experiment 14
AIM:

To design a flow chart for chosen system.

THEORY:

A flowchart is a type of diagram that represents an algorithm, workflow or process, showing

the steps as boxes of various kinds, and their order by connecting them with arrows. This
diagrammatic representation illustrates a solution model to a given problem.
Flowcharts are used in analyzing, designing, documenting or managing a process or program in
various fields.
Symbols used in designing flow chart:

76
Performance Instruction:
1) Identify various processes, input/output and decision-making statement of the
system and analyze it.
2) Use them to draw flow chart.

Sample Output:

77
Conclusion: Flow chart was made successfully.

VIVA - QUESTIONS:

Q-1. What is a flow chart?

Q-2. Explain symbols used to design flow chart

Q-3. What is benefit of designing a flow chart?

Q-4. At which stage of designing it is designed?

Q-5. Is there any limitation of drawing it?

78
 Experiment 15
AIM:
To draw ER Diagram for chosen system.

THEORY:
An entity relationship model, also called an entity-relationship (ER)
diagram, is a graphical representation of entities and their relationships to
each other, typically used in computing in regard to the organization of
data within databases or information systems. An entity is a piece of data-
an object or concept about which data is stored.
Relationships Between Entities
A relationship is how the data is shared between entities. There are three
types of relationships between entities:
1. One-to-One
One instance of an entity (A) is associated with one other instance of
another entity (B). For example, in a database of employees, each
employee name (A) is associated with only one social security number

(B).

2. One-to-Many
One instance of an entity (A) is associated with zero, one or many
instances of another entity (B), but for one instance of entity B there is
only one instance of entity A. For example, for a company with all
employees working in one building, the building name (A) is associated
with many different employees (B), but those employees all share the
same singular association with entity A.

3. Many-to-Many
One instance of an entity (A) is associated with one, zero or many
instances of another entity (B), and one instance of entity B is associated

79
with one, zero or many instances of entity A. For example, for a company
in which all of its employees work on multiple projects, each instance of
an employee (A) is associated with many instances of a project (B), and at
the same time, each instance of a project (B) has multiple employees (A)
associated with it.

Symbols used to draw ER diagram:

80
Performance Instruction:
1) Identify all entities and their attributes.

2) Identify weak entities, attributes and their identifying relationship.

3) Design ER diagram according to norms.

4) Imply cardinalities on diagram.

81
Sample Output:

ER diagram for Railway Reservation System

82
 Conclusion: ER diagram was made successfully.

VIVA - QUESTIONS:

Q-1. Explain ER diagram

Q-2. What is entity? Explain strong and week entity?

Q-3. What is attributes? Explain different types of attributes?

Q-4. Explain three types of relationship?

Q-5. what is cardinality

83
84