1

LABORATORY FILE : SOFTWARE ENGINEERING .

SUBJECT CODE: UGCA: 1924

BACHELOR OF COMPUTER APPLICATIONS

SUBMITTED BY: SUBMITTED TO:

Sahil Kumar Prof. Gurlin Kaur Dhaliwal

COLLEGE ROLL NO: 226617

UNIVERSITY ROLL NO: 2200315

DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

BABA BANDA SINGH BAHADUR ENGINEERING

COLLEGE FATEGARH SAHIB

 ➖01
2

Practical No.

Aim:- SDLC - A case study on Library Automation System.

SDLC (Software Development Life Cycle).

SDLC- It is a process followed for a software organisation. It consists of a detailed plan

describing how to develop, maintain, replace and alter or enhance specific software. The life
cycle defines a methodology for improving the quality of software and the overall development
process.
1. Recognizing the need ➖ 3

In existing systems all the transactions of books are done manually, So taking more time for a
transaction like borrowing a book or returning a book and also for searching for borrower and
books. Another major disadvantage is that to prepare the list of books borrowed and the
available books in the library will take more time, it is done as a one day process for verifying
all records.

2. Feasibility study ➖
Considering the requirements, a full-scale feasibility study was undertaken for testing the
possibility of computerisation of the library.

The feasibility study was carried out under the following four areas ➖
(a) Economical Feasibility,
(b) Technical Feasibility,
(c) Operational Feasibility,
(d) Legal Feasibility .

(a). Economical Feasibility ➖

This evaluation often includes a cost/benefit analysis of the project, which assists businesses
in determining the viability, cost, and advantages of a project before allocating financial
resources. It also functions as an impartial project evaluation and enhances project credibility
by assisting decision-makers in determining the positive economic advantages that the
proposed project would give to the business.

(b). Technical Feasibility ➖

It assists companies in determining whether technical resources are enough and whether the
technical team is capable of translating ideas into workable systems. Technical feasibility also
includes an assessment of the proposed system’s hardware, software, and other technological
needs.

(c). Operational Feasibility ➖

This evaluation entails researching to establish whether—and how well the organisation’s
needs can be addressed by finishing the project. Operational feasibility studies also look at
how a project plan meets the criteria specified during the system development requirements
analysis phase.

(d). Legal Feasibility ➖

This evaluation looks at if any component of the planned project violates any regulations, such
as zoning regulations, data protection legislation, or social media legislation.
 4

3. Initial investigation ➖
● Gather, analyse, and validate the information.
● Define the requirements and prototypes for the new system.
● Evaluate the alternatives and prioritise the requirements.
● Examine the information needs of the end-user and enhance the system goal.
● A Software Requirement Specification (SRS) document, which specifies the software,
hardware, functional, and network requirements of the system is prepared at the end of
this phase.

★ CHARACTERISTICS OF THE SYSTEM ➖

The system allows us to know the total no. of different subjects and authors presents and
initially available in the library.

The main features of the system are: ➖

1. User login/logout, user Administration.
2. Add, edit and delete the book's information.
3. Search and view the book's information.
4. Define Student.
5. Add, edit and delete Student information.
6. Search and view the Student, and return the book from Student to Library.
7. Issue a book to the Student, and return the book from the Member to Library.
8. Reports based on existing records.
9. The databases can be backed up with OS backup utility.

4. Analysis and Specification ➖

● Includes the design of application, network, databases, user interfaces, and system
interfaces.
● Transform the SRS document into logical structure, which contains a detailed and
complete set of specifications that can be implemented in a programming language.
● Create a contingency, training, maintenance, and operation plan.
● Review the proposed design. Ensure that the final design must meet the requirements
stated in the SRS document.
● Finally, prepare a design document which will be used during next phases.
 5

5. System Analysis and Design: ➖

Library management systems are designed to manage the movement of books and maintain
records of the members in a library.

The system requirement in library management focuses on the possibility of searching for
books by title, author or subject by the member. They should be able to locate a book
physically by the unique identification code and the rack number for each book. The system
should provide details on the books held by the members. The system should limit the number
of books that can be taken and the number of days that a book can be kept for.

Data Flow Diagram (DFD) depicts the flow of information and the transformation applied
when a data moves in and out from a system. The overall system is represented and
described using input, processing and output in the DFD.

The inputs can be: ➖

● Book request when a student requests for a book.
● Library card when the student has to show or submit his/her identity as a proof.

➖
The overall processing unit will contain the following output that a system will produce
or generate:
● Books will be the output as the book demanded by the student will be given to them.
● Information of the book should be displayed by the library information system that can
be used by the student while selecting the book which makes it easier for the student.

6. Coding: ➖
The system design phase is followed by the coding step. In this stage, programmers begin
creating the entire system by writing code in the programming language of their choice. Tasks
are broken down into pieces or modules and given to different developers during the coding
phase. It is the stage of the software development life cycle that lasts the longest.

The developer must adhere to specific coding standards during this phase. To create and
implement the code, they must also employ programming tools like compilers, interpreters, and
debuggers.

7. Testing: ➖
When the software is ready, it is installed in the testing setting. The testing crew starts by
checking the system's overall functionality. This is done to make sure the entire application
functions in line with the client's requirements.
 6
The QA and testing team may discover certain flaws or faults at this phase, which they report
to developers. The bug is fixed by the development team and sent back to QA for another test.
This process continues until the programme is bug-free, reliable, and working according to the
business needs of that system.

8. Deployment: ➖
The Deployment Phase in SDLC includes the work necessary to deploy the final solution into
the target production environments. Plus, creating guides for installation, system operations,
system administration, and end-user functionality.

9. Maintenance: ➖
Once the system is deployed, and customers start using the developed system, following 3
activities occur.
● Bug fixing – bugs are reported because of some scenarios which are not tested at all
● Upgrade – Upgrading the application to the newer versions of the Software.
● Enhancement – Adding some new features into the existing software.
 7

Practical No. ➖ 02
AIM:- Select & Develop the waterfall model, prototype model and spiral model the
products.

● Banking management system

● College Management system

Sure, let's outline the development approach for the Banking Management System, College
Management System, using the Waterfall model, Prototype model, and Spiral model.

1. Waterfall Model: ➖
The Waterfall model is a linear sequential approach where progress flows in one direction
downwards through several phases like Requirements, Design, Implementation, Testing,
Deployment, and Maintenance.

Waterfall Model.
 8

Banking Management System: ➖

Requirements Phase: Gather requirements from stakeholders including bank staff and
customers.

1. Design Phase: Design the system architecture, database schema, user interfaces, etc.

2. Implementation Phase: Develop the banking system software according to the design.

3. Testing Phase: Conduct thorough testing including unit testing, integration testing,
system testing, and user acceptance testing.

4. Deployment Phase: Deploy the system in the bank branches.

5. Maintenance Phase: Provide ongoing support and maintenance for the system.

College Management System: ➖

The same phases as above apply to the College Management System, tailored to the
requirements of managing a college's operations.
2. Prototype Model: ➖ 9

The Prototype model focuses on building a prototype quickly, allowing stakeholders to interact
with the system early for feedback and improvements.

Banking Management System: ➖

1. Prototype Development: ➖ Develop a basic prototype with essential features such as
customer registration, account management, and transactions.

2. Prototype Demonstration: ➖ Present the prototype to bank stakeholders for

feedback.

3. Prototype Refinement: ➖ Based on feedback, refine the prototype to incorporate

necessary changes.

4. Final Development: ➖ Develop the complete banking management system

incorporating all required features.

5. Testing and Deployment: ➖Test the system thoroughly and deploy it in bank
branches.

College Management System: ➖

Follow a similar process but tailored to the needs of a college, with features like student
registration, course management, grades, etc.
 10

3. Spiral Model: ➖
The Spiral model combines the iterative nature of Prototyping with the systematic aspects of
the Waterfall model. It involves repeated cycles of prototyping, development, and testing.

Spiral Model.
 11

Banking Management System: ➖

1. Identify Objectives: ➖ Define objectives for each iteration, such as adding new
features or improving existing ones.

2. Risk Analysis:➖ Identify and analyze potential risks associated with the objectives.
3. Prototyping: ➖ Develop a prototype addressing the objectives identified.

4. Development: ➖ Based on the prototype, develop the banking management system

incrementally.

5. Testing:➖ Test each iteration thoroughly.

6. Evaluation: ➖ Evaluate the results of each iteration and gather feedback from
stakeholders.

7. Next Iteration: ➖Plan the next iteration based on feedback and objectives.
College Management System: ➖
Follow a similar iterative process, adapting it to the needs of managing a college's operations.

Each of these models offers different benefits and is suitable for different project requirements.
The choice depends on factors like project complexity, time constraints, and stakeholder
preferences.
 12

Practical No. ➖ 2.1

➖
★ Develop a college management system using the waterfall model, with
explanations for each phase:

Here's a development plan for a College Management System (CMS) using the Waterfall
model, with explanations for each phase:

1. Requirements Gathering Phase: ➖

● Objective: Gather detailed requirements from stakeholders including administrators,
faculty, students, and staff to understand the needs and functionalities expected from the
CMS.

★ Activities:
➔ Conduct interviews, surveys, and workshops with stakeholders to identify their needs
and preferences.
➔ Document functional requirements such as student registration, course management,
attendance tracking, grades management, etc.
 13
➔ Document non-functional requirements such as performance, security, scalability, etc.

● Output: Requirement Specification Document (RSD) detailing all functional and

non-functional requirements.

2. Design Phase: ➖
● Objective: Design the architecture and user interface of the CMS based on the
gathered requirements.

★ Activities:
➔ Architectural Design: Define the system architecture including database schema,
modules, and their interactions.
➔ User Interface Design: Design user-friendly interfaces for administrators, faculty, and
students.
➔ Database Design: Design the database schema to store information such as student
records, course details, etc.

● Output: Design Documents including system architecture diagrams, UI mockups, and

database schema.

3. Implementation Phase: ➖
● Objective: Develop the CMS software based on the designed architecture and
specifications.

★ Activities:
➔ Coding: Write code for different modules of the CMS using programming languages
such as Java, Python, etc.
➔ Database Implementation: Implement the database using appropriate technologies like
MySQL, PostgreSQL, etc.
➔ Integration: Integrate different modules to ensure they work together seamlessly.

● Output: Working software modules ready for testing.

4. Testing Phase: ➖
● Objective: Ensure that the CMS meets the specified requirements and functions
correctly.

★ Activities:
➔ Unit Testing: Test individual modules to ensure they work as expected.
 14
➔ Integration Testing: Test the integration of different modules to verify that they interact
correctly.
➔ System Testing: Test the entire CMS system to validate its functionality, performance,
and security.
➔ User Acceptance Testing (UAT): Involve stakeholders to test the system in a real-world
environment.

● Output: Test reports, including any identified issues or bugs.

5. Deployment Phase: ➖
● Objective: Deploy the CMS system in the college environment for everyday use.

★ Activities:
➔ Installation: Install the CMS software on appropriate servers or cloud platforms.
➔ Configuration: Configure the system settings according to the college's requirements.
➔ Training: Provide training to administrators, faculty, and staff on how to use the CMS.

● Output: Deployed and configured CMS system ready for use.

6. Maintenance Phase: ➖
● Objective: Provide ongoing support and maintenance for the CMS to ensure its smooth
operation.

★ Activities:
➔ Bug Fixes: Address any issues or bugs reported by users.
➔ Updates and Enhancements: Continuously update and enhance the CMS to add new
features or improve existing ones based on user feedback.
➔ Technical Support: Provide technical assistance to users as needed.

● Output: Updated and well-maintained CMS system ensuring its reliability and usability
over time.

Following the Waterfall model ensures a systematic and structured approach to developing the
College Management System, with each phase building upon the outputs of the previous
phase. This model is suitable when requirements are well-understood and unlikely to change
significantly during the development process.
 15

Practical No. ➖03

AIM:- Prepare SRS documentation using IEEE format on Library on
Hospital managements system.

SRS (Software Requirements Specification) document for a Hospital Management

System, formatted according to IEEE (Institute of Electrical and Electronics Engineers)
standards. Please note that this is a template and may need further customization based on
specific project requirements.

Software Requirements Specification ➖

★ Hospital Management System .
Table of Contents ➖ 16

1. Introduction ➖

1.1 Purpose ➖
The purpose of this document is to provide a detailed description of the requirements for the
Hospital Management System. It outlines the features, functionalities, and constraints of the
system to be developed.

1.2 Scope ➖
The Hospital Management System is aimed to streamline the administrative, clinical, and
financial functions of a hospital. It includes modules for patient management, appointment
scheduling, medical records management, billing, and reporting.

1.3 Definitions, Acronyms, and Abbreviations ➖

● HMS: Hospital Management System
● EMR: Electronic Medical Records
● API: Application Programming Interface

2. Overall Description ➖
2.1 Product Perspective ➖
The Hospital Management System will be a standalone application that integrates with existing
hospital infrastructure such as databases and medical devices. It will interact with external
systems for tasks such as insurance verification and lab result retrieval.
 17

2.2 Product Features ➖

● Patient registration and management
● Appointment scheduling
● Electronic Medical Records (EMR)
● Billing and invoicing
● Reporting and analytics

2.3 User Classes and Characteristics ➖

● Administrators: Manage system settings, user accounts, and overall system
configuration.

● Doctors: Access patient records, prescribe medications, and schedule appointments.

● Nurses: Record patient vitals, administer medications, and update patient statuses.

● Patients: Access personal health records, schedule appointments, and view bills.

2.4 Operating Environment ➖

The Hospital Management System will run on a web-based platform and be accessible via web
browsers. It will be compatible with modern browsers such as Google Chrome, Mozilla Firefox,
and Microsoft Edge.

2.5 Design and Implementation Constraints ➖

● The system must comply with relevant healthcare regulations such as HIPAA (Health
Insurance Portability and Accountability Act).

● The system must be scalable to accommodate future growth in patient volume and
functionality.

2.6 User Documentation ➖

User documentation including user manuals, tutorials, and FAQs will be provided to help users
navigate and utilise the system effectively.

3. External Interface Requirements ➖

3.1 User Interfaces ➖
The system will have intuitive and user-friendly interfaces for different user roles, including
administrators, doctors, nurses, and patients.
 ➖
18
3.2 Hardware Interfaces
The Hospital Management System will interface with existing hospital hardware such as
computers, tablets, and printers.

3.3 Software Interfaces ➖

The system will integrate with external software systems for tasks such as insurance
verification, lab result retrieval, and pharmacy management.

3.4 Communication Interfaces ➖

The system will support secure communication protocols such as HTTPS for data transmission
between clients and servers.

4. System Features ➖
Feature 1: Patient Registration ➖
● Description: Allows hospital staff to register new patients into the system.
● Inputs: Patient demographics, insurance information, emergency contacts.
● Outputs: Unique patient identifier, registration confirmation.

Feature 2: Appointment Scheduling ➖

● Description: Enables patients to schedule appointments with doctors.
● Inputs: Patient information, preferred date and time.
● Outputs: Appointment confirmation, reminder notifications.

(Continue listing features as necessary)

5. Non-functional Requirements ➖
5.1 Performance Requirements ➖
● The system must respond to user actions within 2 seconds.
● The system must handle a minimum of 100 concurrent users.

5.2 Security Requirements ➖

● User authentication and authorization mechanisms must be implemented to ensure data
privacy.
● Data encryption must be used for transmitting sensitive information over the network.

(Continue listing non-functional requirements as necessary)

6. Other Requirements ➖ 19

● The system must provide support for multiple languages to accommodate diverse user
populations.
● The system must have a backup and disaster recovery plan to prevent data loss.

7. Appendix ➖
● Appendix A: Glossary of Terms

This is a basic template for an SRS document for a Hospital Management System. You would
typically expand on each section with more detailed information and requirements specific to
your project. Additionally, you may include diagrams, mockups, and other supplementary
materials to enhance the document.
 ➖ 04
20

Practical No.

AIM:- Study and Working of smart draw.

SmartDraw is a diagramming software that allows users to create professional-looking

diagrams, flowcharts, floor plans, organisational charts, mind maps, and many other types of
visuals. It provides a user-friendly interface and a vast library of templates and symbols to
streamline the diagram creation process.

Here's a brief overview of its features and how it works: ➖

Features of SmartDraw: ➖
 21
1. Extensive Template Library: SmartDraw offers a wide range of templates for various
diagram types, saving users time and effort in creating diagrams from scratch.

2. Intelligent Formatting: It automatically aligns and arranges shapes to create neat and
professional-looking diagrams.

3. Collaboration Tools: SmartDraw allows users to collaborate in real-time by sharing

diagrams with colleagues and clients. It also integrates with popular collaboration
platforms like Microsoft Teams, Microsoft Office, Google Workspace, and Dropbox.

4. Integration with Other Tools: It seamlessly integrates with other applications such as
Microsoft Office, G Suite, and popular project management tools like Trello and Jira.

5. Customization Options: Users can customise shapes, colours, and styles to match
their preferences or corporate branding.

6. Accessibility: SmartDraw provides accessibility features such as screen reader support

and keyboard shortcuts to make it usable for people with disabilities.

7. Cross-Platform Compatibility: It is available for Windows, Mac, and online, allowing

users to access and work on their diagrams from any device with an internet connection.

8. Automation: SmartDraw offers automation features to streamline repetitive tasks and

save time in diagram creation.

How SmartDraw Works: ➖

 ➖
22
1. Choosing a Template: Users start by selecting a template from the extensive library
provided by SmartDraw. Templates are available for various diagram types, including
flowcharts, floor plans, org charts, and more.

2. Creating the Diagram: ➖ Once a template is selected, users can drag and drop
shapes, text boxes, and other elements onto the canvas to create the diagram.
SmartDraw offers a vast library of shapes and symbols specific to each template type.

3. Customising the Diagram: ➖ Users can customise the appearance of the diagram by
changing colours, fonts, and styles. They can also add images, logos, and annotations
to enhance the visual appeal and convey information effectively.

4. Adding Data and Connecting Shapes: ➖ SmartDraw allows users to link data to
shapes and automatically generate diagrams based on the data. Users can also connect

➖
shapes with lines and arrows to represent relationships and flow.
5. Collaboration and Sharing: Once the diagram is created, users can collaborate with
others by sharing the diagram via email, link, or embedding it on a website.
Collaborators can view, comment, and edit the diagram in real-time, facilitating
teamwork and communication.

6. Exporting and Saving: ➖ SmartDraw allows users to export diagrams in various

formats, including PDF, PNG, JPEG, and Microsoft Office formats. Users can also save
their diagrams to the cloud or their local devices for future reference and editing.

Symbols & Diagram are Use in Smartdraw ➖

Symbols and their Functions ➖ 23
 24

Flowcharts ➖

Overall, SmartDraw is a versatile and user-friendly diagramming tool that simplifies the
process of creating professional-quality diagrams for various purposes, from project planning
to business presentations. Its extensive features and ease of use make it a valuable tool for
individuals and organisations alike.
 ➖ 05
25

Practical No.

AIM : ➖ Works , Features and Types of DFD (Data Flow Diagram) .

Data Flow Diagrams (DFDs) are graphical representations used in systems analysis and
software engineering to model the flow of data within a system. They depict how data moves
through a system, from input to processing to output. DFDs are commonly used during the
requirements analysis phase to understand and document the data requirements of a system.

Data Flow Diagram Way.

Here are the key features and how DFDs work: ➖

Features of DFDs: ➖
 26

1. Data Flow: DFDs represent the flow of data through processes within a system. Arrows
are used to indicate the direction of data flow, from sources to destinations.

2. Processes: Processes in DFDs represent the transformation of data. They receive input
data, perform some processing or manipulation, and produce output data. Processes
are depicted as rectangles in DFDs.

3. Data Stores: Data stores represent the storage of data within a system. They can
represent databases, files, or any other storage medium. Data stores are depicted as
rectangles with two parallel lines at the top and bottom.

4. External Entities: External entities represent sources or destinations of data that

interact with the system but are outside of its boundaries. They can be users, other
systems, or external organisations. External entities are depicted as squares in DFDs.

5. Data Flows: Data flows represent the movement of data between processes, data
stores, and external entities. They are depicted as arrows in DFDs and indicate the
direction of data flow.

Working of DFDs: ➖

Working Way of DFD.

1. Identify System Boundaries: The first step in creating a DFD is to identify the
boundaries of the system being analysed. This involves determining what is inside the
system and what is outside (external entities).

2. Identify Data Flows: Identify the data flows into and out of the system. This includes
understanding where the data originates from (external entities) and where it goes to
(external entities, processes, or data stores).
 27
3. Identify Processes: Identify the processes within the system that transform or
manipulate the data. This involves understanding the tasks or functions that need to be
performed to achieve the system's objectives.

4. Connect Components: Connect the external entities, processes, and data stores using
data flows. Arrows indicate the direction of data flow between these components.

5. Refine the Diagram: Refine the DFD by adding details such as data store names,
process descriptions, and data flow descriptions. This helps to clarify the flow of data
and the functions performed by each process.

6. Validate and Verify: Validate the DFD to ensure that it accurately represents the data
flow within the system and verifies that it meets the requirements of the stakeholders.

★ Data Flow Diagrams (DFDs) are categorised into different levels based on the level
of detail they represent and the scope of the system.

● The commonly used types of DFDs include: ➖

1. Level 0 DFD (Context Diagram): ➖
This is the highest level of abstraction in a DFD.
It represents the entire system as a single process surrounded by external entities.
It provides an overview of the system and its interactions with external entities.

Example ➖
 2. Level 1 DFD: ➖ 28

Level 1 DFDs decompose the main process of the context diagram into smaller subprocesses.
It provides a more detailed view of the system by breaking down the main process into its
constituent processes.
Each subprocess may further decompose into lower-level processes or data stores if
necessary.

Example ➖

3. Level 2 DFD and Beyond: ➖

Level 2 DFDs continue the decomposition of processes from the Level 1 DFD.
They provide even more detailed views of the system by breaking down sub processes into
smaller sub processes or data flows.
This decomposition continues until the desired level of detail is reached.

Example ➖
 29

Example: ➖
★ Consider a simple DFD for a student registration system: ➖

● External entities: Students, Registrar's Office

● Processes: Register Student, Update Student Information
● Data stores: Student Database

The DFD would show data flows from the Students external entity to the Register Student
process, and from the Register Student process to the Student Database data store,
representing the flow of student registration data through the system.

In summary, Data Flow Diagrams (DFDs) are useful tools for visualising and understanding the
flow of data within a system. They provide a clear and concise representation of how data
moves through processes and are valuable for requirements analysis and system design.
30