BCS051 : INTRODUCTION TO SOFTWARE ENGINEERING
BACHELOR OF COMPUTER APPLICATIONS (BCA) (Revised). Term-End Examination June, 2016, BCS-051 : INTRODUCTION TO SOFTWARE ENGINEERING. Ignou solved question paper for BCS051
Term-End Examination June, 2016
BCS-051 : INTRODUCTION TO SOFTWARE ENGINEERING
1. (a) Explain IEEE SRS format and apply it to develop SRS for "Online Railway Reservation System". Make necessary assumptions.
Sol: IEEE SRS Format
The IEEE SRS (Software Requirements Specification) is a standard document format defined by IEEE 830-1998. It provides a comprehensive structure to define what the software system should do. It acts as a bridge between client expectations and developer implementation.
Main Components of IEEE SRS:
Introduction
Purpose
Scope
Definitions, Acronyms, Abbreviations
References
Overview
Overall Description
Product Perspective
Product Functions
User Characteristics
Constraints
Assumptions and Dependencies
Specific Requirements
Functional Requirements
Non-functional Requirements
Interface Requirements (User Interface, Hardware, Software, Communications)
Appendices (Optional)
Glossary, Data Dictionary, Use Case Diagrams, etc.
The SRS ensures clarity, traceability, and a single point of reference for developers, testers, and stakeholders.
SRS for "Online Railway Reservation System"
1. Introduction
1.1 Purpose
This SRS defines the functionalities, interfaces, and performance criteria for the Online Railway Reservation System (ORRS). The aim is to digitalize the ticket booking process for users and provide easy train management for administrators.
1.2 Scope
The system will enable:
Online user registration and login
Search for trains between two stations
Real-time seat availability
Ticket booking and cancellation
Admin management of train data and reports
1.3 Definitions, Acronyms and Abbreviations
TermDefinitionORRSOnline Railway Reservation SystemUIUser InterfaceDBMSDatabase Management SystemPNRPassenger Name Record
1.4 References
IEEE Std 830-1998
IGNOU Software Engineering Textbook
Indian Railways Passenger Reservation System Manuals
1.5 Overview
This document outlines system architecture, requirements, constraints, and use cases for the ORRS.
2. Overall Description
2.1 Product Perspective
The ORRS is a standalone web-based application that connects to a backend MySQL database. It is intended to replace manual reservation counters.
2.2 Product Functions
User registration and authentication
Train search and schedule display
Ticket booking with fare calculation
View and cancel booked tickets
Admin panel to manage trains, stations, and bookings
2.3 User Characteristics
User TypeDescriptionEnd UsersGeneral public booking train ticketsAdminsRailway staff managing system data
2.4 Constraints
The system must use secure HTTPS connection
Must be compatible with all modern browsers
Data must be backed up daily
2.5 Assumptions and Dependencies
Users will have internet access
Admins will update train schedules and availability regularly
Payment gateway APIs are functioning correctly
3. Specific Requirements
3.1 Functional Requirements
FR No. Requirement Description
FR1 Users shall register using email, phone, and password
FR2 sers shall log in using secure authentication
FR3 Users can search trains by source, destination, and date
FR4 System shall show seat availability in real time
FR5 Users can select class, enter passenger details, and make payment
FR6 System shall generate a unique PNR and show booking details
FR7 Users can view/cancel tickets before departure
FR8 Admin can add/edit/delete train details
FR9 Admin can view system usage and booking reports
3.2 Non-Functional Requirements
NFR No. Description
NFR1 The system should support up to 500 concurrent users
NFR2 Response time should be < 3 seconds per operation
NFR3 User data must be stored in encrypted form
NFR4 System should maintain 99.9% uptime
3.3 Interface Requirements
3.3.1 User Interface
Clean and responsive UI with options for login, search, booking, and history
Admin dashboard with analytics and controls
3.3.2 Hardware Interface
Compatible with desktops, laptops, and smartphones
3.3.3 Software Interface
Frontend: HTML, CSS, JavaScript
Backend: PHP/Node.js
Database: MySQL
API: Payment gateway integration (e.g., Razorpay/Paytm)
3.3.4 Communication Interface
HTTP/HTTPS protocol for client-server communication
4. Use Case Diagram
(b) What is Use Case Diagram ? Draw a Use Case Diagram for Bank ATM System.
Sol: It shows the relationship between the user and the system and createsthe boundary of the system. This diagram is used to:
Understand the requirements clearly.
Enable users to understand the system.
Generate test case to validate the system.
Build project schedule.
In Use case diagram, we use seven symbols. They are given below:
System: It shows the boundary of the system and is represented by a
rectangle
Actor: It represents the user or people or device which interacts with the system. Actor is represented as given in Figure
Use Case: It shows the desired function of the system. It defines the requirements of the system. Actors gives input to the use case and use case provides output for the given input. It can be represented as given in Figure
Association: It is a structural relationship that describes a set of links (a link being a connection among objects). It is represented by a line (may be directed), including labels such as multiplicity and role name as given in Figure
Dependency: This is used to show the relationship between use cases and is
represented by a directed dashed line and occasionally includes label.
Generalization: It shows the concept of inheritance among use cases and actors. It is represented by a line with a hollow arrowhead pointing towards the parent.
Realization: It is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. It is represented by a dashed line with a hollow arrowhead pointing towards the parent.
(c) What is Spiral Model for software development ? Explain its primary activities in brief.
Sol: Spiral Model-->
This model can be considered, as the model, which combines the strengths of various other models. This is made by representing the iterative development cycle as an expanding spiral. The following are the primary activities in this model:
Finalising Objective: The objectives are. set for the particular phase of the project. .
Risk Analysis: The risks are identified to the extent possible. They are analysed and necessary steps are taken.
Development: Based on the risks that are identified, an SDLC model is selected and is followed. .
Planning: At this point, the work done till this time is reviewed. Based on the review, a decision regarding whether to go through the loop of spiral again or not will be decided. If there is need to go, then planning is done accordingly.
The inner cycles of the spiral model represent early phases of requirements analysis and after prototyping of software, the requirements are refined. In the spiral model, after each phase a review is performed regarding all products developed upto that point and plans are devised for the next cycle. This model is a realistic approach to the development of large scale software. It suggests a systematic approach according to classical life cycle, but incorporates it into iterative framework. It gives a direct consideration to technical risks.
2. (a) Draw the first two levels of DFDs for "Online Railway Reservation System". Make necessary assumptions wherever, required.
Sol: Level 0 DFD for Online Railway Reservation System
Level 1 DFD
(b) Define the term 'Coupling'. Explain the differences between coupling and cohesion
Sol: Coupling indicates the dependencies across different modules. If, a module is dependent onmultiple functions in another module, then it is known as strong coupling; lesser number of dependencies indicate loose coupling.
Types of Coupling
• Content coupling: In this type of coupling, one module is dependent and updates the internal state of another module. This is a very tight form of coupling.
• Common coupling: If modules share the same global data, it is known as common coupling.
• Control coupling: If a function argument passed from the first module controls the logic and order of instructions in another module, for instance, it is an illustration of a control coupling if we pass control flags and switches from one module to function in another module through which the sequence of steps and branching can be varied, it forms control coupling.
• Data coupling: If two modules are coupled by a function parameter it is said to be data coupling.
3. (a) Draw a GANTT chart for the development of "Online Railway Reservation System".
Sol: GANTT chart is a project planning tool that can be used to represent the timing of tasks required to complete a project. In a GANTT chart, each task takes up one row, Dates run along the top in increments of days, weeks or months, depending on the total length of the project. The expected time fOJ:each task is represented by a horizontal bar whose left end marks the expected beginning of the task and whose right end marks the expected completion date. Tasks may run sequentiaUy, in parallel or overlapping,
(b) Explain Software Development Life Cycle (SDLC) in brief
Sol: As various activities are being performed in software process, these activities are categorized into groups called phases. Each phase performs well defined activities. . The various steps (called phases) which are adopted in the development of this process are collectively temied as Software Development Life Cycle (SDLC)
The various phases of SDLC are discussed below. Normally, these phases are performed lineally or circularly, but it can be changed according to project as well.
Requirements Analysis
Design
Coding
Software
Testing
Maintenance
Requirements Analysis
In the requirements analysis phase, the requirements are properly defined and noted down. The output of this phase is SRS (Software Requirements Specification) document written in natural language. According to IEEE, requirements analysis.
Design
Design phase of software development deals with transforming the customer's requirements intoa logically working system.
Design is performed in the followin-g two steps:
(i) Primary Design Phase: In this phase, the system is designed at block level. The blocks are created on the basis of analysis done in the problem identification phase.
(ii) Secondary Design Phase: In the secondary design phase the detailed design of every block is performed.
The general tasks involved in the design process are the following:
Design various blocks for overall system processes.
Design smaller, compact, and workable modules in each block.
Design various database structures.
Specify details of programs to achieve desired functionality.
Design the form of inputs, and outputs of the system .
Perform documentation.of the design.
System reviews.
The following points should be kept in mind while performing the design:
Practicality: This ensures that the system is stable and can be operated by a person of average intelligence. .
Efficiency: This involves accuracy, timeliness and comprehensiveness of system output.
Flexibility: The system could be modifiable depending upon changing needs of the user.
Securlty: Should cover areas of hardware reliability, fall back procedures, security of data and provision for detection of fraud.
Coding
In this phase, the design document is coded according to the module specification. This phase transforms the SDD(Software Design Document) document into a high. level language code.
Coding standards generally give the guidelines about the following:
Name of the module
Internal and External documentation of source code
Modification history
Uniform appearance of codes.
Testing
In the process of testing, an attempt is made to detect errors, to correct the errors in order to develop error free software. The testing is performed keeping the user's requirements in mind and before the software is actually launched on a real system, it is tested.
The following are some of the strategies of testing:
(i) Code Testing: The code testing strategy examines the logic of the system. In this, the analyst develops test cases for every instruction irrthe code.
(ii) Specification Testing: In this, testing with specific cases is performed. The test cases are developed for each condition or combination of conditions and submitted for processing. It can only find the presence of errors.
Some testing techniques are th.eblack box and the white box methods.
White Box Testing: This method, also known as glass box testing, is performed early in the testing process. Using this, the software engineer can derive a tests that guarantees that all independent paths within the module have been exercised at least once.
Black Box Testing: This is applied during the later stage of testing: It enables the software developer to derive a set of input conditions that will fully exercise the functional requirements of a program.
Maintainance:
.Software maintenance is done because of the following factors.
(i) To rectify the errors which are encountered during the operation of software.
(ii) To change the program function to interface with new hardware or software.
(iii) To change the program according to increased requirements.
There are three categories of maintenance:
Corrective Maintenance
Adaptive Maintenance
Perfective Maintenance
4. (a) What is Software configuration Management ? Explain the necessity of software configuration management in brief.
Sol : A Software Configuration Management (SCM) Plan defines the strategy to be used for change management. A slightly more formal definition of software configuration management can be: SCM is a software-engineering discipline comprising the tools and techniques (processes or methodology) that a company uses to manage change to its software assets.
The following are some of the important problems that appear if SCM is not used.
(a) Inconsistency Problem: The problem of inconsistency arises when the SCIs(Software Configuration Items) are replicated. Consider a situation where every software engineer has a personal copy of the SCI (e.g. source code). most of the times the changes are not communicated to the team thus making the different copies of the SCI ' inconsistent, leading to the failure of the integrated product.
(b) Concurrent Access: Simultaneous access and modific-ations of the different parts of an SCI may lead to unintentional overwriting of the changes made by the other teammates. Thus the final SCI may be deemed unusable for all.
(c) Stable Development Environment:With an effective SCM in place, the project leader freezes the SCIs to form a base line. Anyone needing an SCI under configuration control, he is providedwith a copy of the base line item.
(d) System Accounting and Maintaining Status Information: System accounting keeps track of who made a particular change and when the change was made.
(e)Handling Variants: Existence of variants of a software product causes some peculiar problems. Suppose, somebody has several variants of the same module, and finds a bug in one of them. Then, it has to be fixed in all versions and revisions. To do it efficiently, he should not have to fix it in each and every version and revision of the software separately.
(b) Write a short note on Software Quallity Assurance (SQA).
Sol: The term "Software Quality" refers to conformance to explicitly stated requirements and standards, as well as implicit characteristics that customers assume will be present in any professionally developed software. The SQA group must look at software from the customer's perspective, as well as assessing its technical merits. Software Quality ". Assurance controls variation among products.
A systematic, planned set of actions necessary to provide adequate confidence that the software development process or the maintenance process of the software system product , . conforms to established functional technical requirements as well as with the managerial requirements of keeping" the schedule and operating within budgetary confines.
Software Quality Assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. It does this by means of audits of the quality management system under which the software system is created. These audits are backed by one or more standards, usually ISO 9000.
5. (a) What is Function Oriented Design ? Explain the key elements and key features of Function Oriented Design.
Sol: Function oriented design essentially deals with creating functions to convert input into the desired output.
The following are the key elements of function oriented design:
Function: It is a unit of code consisting of a sequence of instructions required to perform a specific task.
Function state: It's the data on which a function operates
Sub Function: The main function can be further broken down into smaller re-usable units of code or sub-functions or sub-routines.
The following are the key features of the function oriented design:
Top down decomposition: Once the high level functions are identified; each function is further decomposed into modular sub-functions. For instance, a high level function such as, "Update Person" updates the persons details entirely. can further be broken down into:
UpdatePersonPersonaIDetails to update the personal details of a person such as, name, age, height, date of birth, etc.
UpdatePersonAddressDetails to update the address details of the person.
UpdatePersonContactDetails to update the contact details of the person such as, phone, email, etc .
Function association: Multiple functions are often related for interaction and data sharing. For instance, in the above example, the main function "Update Person" invokes sub routines such as, UpdatePersonPersonalDetails with person Id which can uniquely identify the person.
Function state sharing: The state of the system is shared among various functions.
(b) Write a short note on Regression Testing.
Sol: Regression testing is an important part of Integration testing. whenever any change is made to the code or a new module is implemented and integrated, all the possible test cases those that have been executed before are also executed again to ensure that no error entered into the already working software. This is what is known as regression testing.
Regression testing is very important and performed by the QA team. A new module is implemented and integrated into the software; it is handed over to the QA team. It is the responsibility of the QA team to run all the possible test cases as part of Regression Testing. If it is observed that a newly added module is affecting the behaviorof modules that were working previously, then it is reported as major bug as part of the failure of integration testing.