SCHOOL OF COMPUTER SCIENCE AND ENGINEERING
[Link]. COMPUTER SCIENCE AND ENGINEERING &
CSE1005 - Software Engineering Laboratory
Slot L7+L8+L21+L22+L39+L40
FALL 2021-22
Lab Manual
Faculty In charge:
[Link], Associate Professor, SCOPE, VIT-AP University
1
LIST OF EXPERIMENTS
Page
Ex. No Title
Number
1 1. Problem Analysis - Overview - Scope 3
2 [Link] Analysis - Objectives - Infrastructure 7
[Link] - description of individual phase/mode - user characteristics -
3 8
general constraints
[Link] - Assumptions: dependency - Function requirements - input and
4 9
output
5 [Link] Modeling: Architecture, Use cases 12
6 [Link] Modeling – Activity 13
7 [Link] Modeling – DFD 14
8 [Link] Modeling – Class 15
9 [Link] - Database Structure 16
10 [Link] – Coding 17
11 [Link] Testing - Test Plan 18
Project Presentation with Demo and Report Submission
2
[Link] 1
Title 1. Problem Analysis - Overview - Scope
Preparations:
Defining the problem statement and format it.
Q & A session to review analysis and design concepts.
Use Case Diagram Class Diagram
1. What is Actor? 1. Aggregation
2. What is Use case? 2. Composition
3. What is extends and uses? 3. Dependency
4. What is the Viewpoint of Use Case 4. Realization
Diagram? 5. Stereotype
5. What is good day path? 6. Visibility of members
Data flow diagram ER Diagram
1. Source 1. Strong entity
2. Sink 2. Weak entity
3. Data Store 3. Has-a relationship
4. Data flow 4. Cardinality
5. Control flow 5. Types of Keys
6. Decomposition
Questions:
1. In Banking application CreditCardUser, DebitCardUser, Bank Manager
2. Relationship between use cases withdraw and print
3. Relationship between use cases withdraw and balance check
4. Relationship between money and purse
5. Relationship between paper and notebook
6. Relationship between paper and file
7. Difference between status and PIN number
3
8. Relationship between Licence and a License Holder
9. Relationship between Employee and dependant
10. Keys of table Customer number/ Customer name and date-of-birth
11. Relationship between Button and ActionEvent
12. Relationship between form and buttons on a form
13. Relationship between List and Linked List
4
E – DOCUMENT MANAGER
Team Members
1. 24MIC7184 - Kamal Sai
2. 24MIC7270 - Vamsi
3. 24MIS7036 - T Bharat Kumar
4. 24MIS7100 - B Karthikeya
5. 24MIC7144 - Karthikeya
5
[Link] 1
Title [Link] Analysis - - Overview - Scope
Problem Statement
In most organizations and institutions, the management of digital documents
is inefficient and lacks proper structure. Files are often stored in multiple
locations without any standardization, making them difficult to track,
retrieve, or update. There is no system in place for maintaining previous
versions of a document, controlling user access, or tracking changes made
by different users.
These limitations can lead to serious issues such as accidental data loss,
unauthorized access to sensitive files, duplication of documents, and
reduced productivity. For example, in an academic or office environment,
users may need to regularly upload, edit, or retrieve documents — but
without version control or role-based permissions, collaboration becomes
risky and unorganized.
To overcome these challenges, there is a need for a centralized E-Document
Manager that allows users to securely upload, organize, and manage
documents with features such as:
[Link]-based access control
[Link] versioning
[Link] and tagging
[Link] logging of user actions
This system will ensure that documents are securely managed, easy to find,
and updated in a controlled and traceable way.
6
[Link] 2
Title [Link] Analysis - Objectives - Infrastructure
0. Problem Analysis
0.1 Overview /Introduction
Provide the Introduction or overview of the project
0.2 Scope
Scope or boundary of the project.
0.3 Objectives/Purpose
Purpose such as who and for what is the product developed.
0.4 Infrastructure / Tools & Technologies
Front-end, back-end , database, Specific tools for implementation and deployment.
7
[Link] 3
Title [Link] - description of individual phase/mode - user characteristics - general
constraints
1. Software Requirement Analysis and Planning
1.1 Description of Individual Module
1.1.1 User Characteristics
List of users and features users are given with.
1.1.2 General Constraints
Constraints of the system
1.1.3 Assumptions
Pre-requisites to use the system
Dependency
Completion of any process related to other.
2.1.4. Functional Requirements
Use Cases – description, input/output
2.1.5 Identify individual module deliverables
List of modules and working
8
[Link] 4
Title [Link] - Assumptions: dependency - Function requirements - input and output
[Link] - Assumptions: dependency - Function requirements - input and output
Functional requirements:
1. Login
Description:
It displays the welcome note to patients, doctors, receptionist and diagnosis,
Input: Username and password.
Output: Depending upon the input, the homepage will display for the user.
2. Patient login
Description:
It will display the appointment date and time of the patient and their diagnosis.
Input: Username and password.
Output: Depending upon the input their diagnosis and appointment schedule will be
displayed. Details related to chosen option.
3. Doctors login
Description:
It will display the treatment details of the patient and their diagnosis.
Input: On entering username and password, doctors can add the details of the
treatment given to the patients.
Output: Patient report and their treatment details will be displayed.
4. Receptionist login
Description:
It will display the list of patients to be treated.
Input: They will enter the patients details like address, mobile no., blood group etc.
9
10
Output: List of patients with their record will be displayed and can also be modified
by the receptionist.
5. Diagnosis login
Description:
Patient details with their symptoms, diagnosis, medicines and ward type will be
displayed.
Input: They can enter the medicines and ward type provided to the patients.
Output: Depending upon the input, full history of the patient will be displayed.
Identify individual module deliverables
Login Module:
Login id and password is given as input for this page. If the password or
username is correct then concerned homepage is shown is shown for respective
user else it will display incorrect username or password.
Patient Module:
Appointment and time of the patient along with their diagnosis will be displayed.
Doctor Module:
Treatment provided to the patients along with their diagnosis will be displayed.
Receptionist Module:
List of patients will be displayed and can also be modified by them.
Diagnosis Module:
Full history of the patients will be displayed.
User characteristics
Administrator:
11
Allow the admission of the patient and assign the roles. Controls overall
operation of the record system.
Diagnostics:
Enter the patient’s diagnosis report and any similar or other medical history of
the patient so that the doctor may treat accordingly.
Doctor:
Update the medication of the patient of which is being currently received by
the patient.
General Constraints:
User id and password for logging into the record system should match the
one generated in the database only then logging in can be allowed.
The user can only update the content which only concern to that respective
field.
The details are available only when the database is active. It won’t be
available otherwise.
Assumption:
Every user knows English. Every user is familiar with their respective
role.
All users shall know their respective ids and password.
Dependency:
The treatment can only be updated after the diagnosis is done and other
medical histories are available for the doctor.
12
[Link] 5
Title [Link] Modeling : Architecture ,Usecases
2. Data Modelling
2.1 Architecture Diagram
2.2 Use-case Diagram
13
[Link] 6
Title [Link] Modeling : Activity
3. Data Modelling
3.3.1 Activity Diagram (Single / Module-wise)
14
[Link] 7
Title [Link] Modeling : DFD
3. Data Modelling
3.4.1 Context Diagram (Logical)
3.4.2 Data Flow Diagram (Physical)
15
[Link] 8
Title [Link] Modeling: Class
6. Data Modelling
3.5 Class Diagram
16
No 9
Title [Link] - Database Structure
7. Development – Database Structure
7.1 E-R Diagram
7.2 Table Design
17
[Link] 10
Title [Link] - Coding
4. Development – Coding
module wise / functionality-wise code (Important part of coding) to be attached
18
[Link] 11
Title [Link] Testing - Test Plan
5. Software Testing
5.1 Test Plan
TES ACTU
T TEST CASE TEST EXPECTE POST AL
S.N CAS DESCRIPTI PRECONDITI DAT D CONDITIO RESUL STATU COMMEN
O E ID ON ON A RESULT N T S TS
Note:
Test cases to be defined based on levels and types of test
o Unit Test
o Integration Test
o System Test
o Acceptance Test etc.,
Faculty Signature
19