3. (a) Draw ERD for OASS. Make necessary assumptions.

and also draw erd

(b) Define Data Dictionary. Consider a Data Element Student. What information about Student is
stored in Data Dictionary ?

#### Assumptions:
1. The system allows students to upload assignments and view their status.
2. Faculty members evaluate and grade the assignments.
3. Each course has multiple assignments.
4. A student can be enrolled in multiple courses, and each course has multiple students.

#### Entities:
1. **Student**: Represents students registered in the system.
- Attributes: `Student_ID (PK)`, `Name`, `Email`, `Contact_Number`, `Enrollment_Number`

2. **Course**: Represents courses offered.

- Attributes: `Course_ID (PK)`, `Course_Name`, `Duration`

3. **Assignment**: Represents assignments related to a course.

- Attributes: `Assignment_ID (PK)`, `Title`, `Description`, `Submission_Date`, `Max_Marks`

4. **Submission**: Represents the assignment submissions made by students.

- Attributes: `Submission_ID (PK)`, `Submission_Date`, `File`, `Grade`, `Feedback`

5. **Faculty**: Represents the faculty responsible for evaluating assignments.

- Attributes: `Faculty_ID (PK)`, `Name`, `Email`, `Department`

#### Relationships:
1. **Student--Course**: Many-to-Many (A student can enroll in multiple courses, and a course can
have many students). Create a junction table: `Enrollment`.
2. **Course--Assignment**: One-to-Many (Each course has multiple assignments).
3. **Student--Submission**: One-to-Many (A student can submit multiple assignments).
4. **Faculty--Assignment**: One-to-Many (A faculty member evaluates multiple assignments).
5. **Assignment--Submission**: One-to-Many (Each assignment has multiple submissions).

#### ERD:
Here is the Entity-Relationship Diagram (ERD):

```
[ Student ] -----< [ Enrollment ] >----- [ Course ] -----< [ Assignment ] -----< [ Submission ]
| ^
| |
| [ Faculty ]
```

I can draw this ERD diagrammatically if you need it as an image.

---

### (b) **Definition of Data Dictionary**

A **Data Dictionary** is a centralized repository that contains details about the structure,
relationships, and attributes of the data used in a system or database. It acts as metadata,
providing information about data elements, tables, fields, and their characteristics.

#### Data Dictionary for Data Element "Student":

The following information about the **Student** data element is typically stored in the Data
Dictionary:
1. **Data Element Name**: `Student`
2. **Description**: Represents a student enrolled in the system.
3. **Attributes**:
- `Student_ID`: Unique identifier for a student.
- `Name`: Full name of the student.
- `Email`: Email address of the student.
- `Contact_Number`: Mobile or phone number.
- `Enrollment_Number`: Enrollment number issued by the university.

4. **Data Type and Size**:

- `Student_ID`: Integer (e.g., 10 digits)
- `Name`: String (e.g., 50 characters)
 - `Email`: String (e.g., 50 characters)
- `Contact_Number`: String (e.g., 15 characters)
- `Enrollment_Number`: String (e.g., 15 characters)

5. **Constraints**:
- `Student_ID`: Primary Key, unique, not null.
- `Email`: Unique, not null.
- `Enrollment_Number`: Unique, not null.

6. **Relationships**:
- Associated with the `Enrollment` table for course registrations.
- Associated with the `Submission` table for assignment submissions.

7. **Default Value**: Not applicable (varies by attribute).

5. (a) Explain various challenges for successful debugging. (b) List any five software testing
tools indicating the testing phase in which they can be employed.

### **Module Testing and Integration Testing**

#### **1. Module Testing** (also known as Unit Testing)

**Definition**:
Module testing is a software testing technique where individual components or modules of the
software are tested in isolation. Each module is verified to ensure that it functions correctly
according to its design and requirements.

**Key Points**:
- Focuses on testing a **single module** or unit of the software.
- The goal is to identify defects within the module and validate its functionality.
- Typically performed by developers during the development phase.
- Relies on stubs and drivers to simulate interaction with other modules if necessary.

**Example**:
In an e-commerce application, a module for "Login" is tested independently to ensure that entering
valid credentials grants access and invalid credentials are rejected.

**Advantages**:
- Early detection of errors in individual components.
- Helps ensure code correctness before integration.
- Easier debugging since the focus is on a specific part of the system.

---

#### **2. Integration Testing**

**Definition**:
Integration testing is a software testing technique where multiple modules or components are
tested together to verify their interaction and data flow. The focus is on ensuring that the
integrated modules work as expected when combined.

**Key Points**:
- Focuses on **interfaces and interactions** between modules.
- Verifies that data flows correctly from one module to another.
- Performed after successful module (unit) testing.
- Can be conducted using one of the following approaches:
- **Top-Down Integration**: Testing starts from the top-level modules and proceeds to lower
levels.
- **Bottom-Up Integration**: Testing begins with lower-level modules and gradually integrates
higher levels.
- **Big Bang Integration**: All modules are integrated and tested simultaneously.
- **Incremental Integration**: Modules are integrated and tested step-by-step.

**Example**:
In the same e-commerce application, integration testing is performed to check how the "Login"
module interacts with the "User Dashboard" module, ensuring that after successful login, the
correct dashboard is displayed.

**Advantages**:
- Detects issues related to interface mismatches or data flow.
- Ensures that modules work cohesively.
- Identifies integration problems early in the testing phase.

---

### **Key Differences Between Module Testing and Integration Testing**

| **Aspect** | **Module Testing** | **Integration Testing**

|
|-----------------------|--------------------------------------------|----------------------------
-----------------|
| **Focus** | Individual module functionality | Interaction between modules
|
| **Scope** | Narrow (single module) | Broader (multiple modules or
systems) |
| **Performed By** | Developers | Testers or specialized
testing teams |
| **Dependencies** | Uses stubs/drivers to simulate other modules | Requires actual
interaction between modules |
| **Objective** | Validate correctness of individual modules | Validate proper data flow
and interface behavior |

Both testing techniques are critical to ensure a high-quality, reliable, and error-free software
system.

2. (a) Draw the zero and first level DFDs for OASS. Make necessary assumptions.
10 (b) Draw GANTT chart for the development of OASS

### **2. (a) Zero and First Level DFDs for OASS (Online Assignment Submission System)**

#### **Assumptions for OASS**:

1. **Users**: Students, Faculty, and Admin.
2. Students can submit assignments, view their submission status, and get feedback.
3. Faculty can upload assignments, evaluate submissions, and provide grades and feedback.
4. Admin oversees user management (e.g., adding/removing users) and system maintenance.

---

#### **Zero-Level DFD (Context Diagram)**

The zero-level DFD provides a high-level overview of the entire system.

**Entities**:
1. **Student**: Submits assignments, views feedback and grades.
2. **Faculty**: Uploads assignments, evaluates submissions, and provides feedback.
3. **Admin**: Manages the system and users.

**Processes**:
- **OASS**: The central system that handles assignment submissions and management.

**Data Flows**:
- **From Student**: Assignment submissions, user details.
- **To Student**: Submission status, feedback, grades.
- **From Faculty**: Assignments, feedback, grades.
- **To Faculty**: Submissions for evaluation.
- **From Admin**: User management data.

---

### **Zero-Level DFD Representation**:

```
+---------------+
| Faculty |
+---------------+
| Upload Assignments, Feedback, Grades
v
+--------------------+
| OASS |
+--------------------+
/ | | \
 / | | \
Student | Admin Faculty
(Submit | Manage (View Submissions)
Assignments) | System Feedback, Grades
```

---

#### **First-Level DFD**

The first-level DFD breaks the system into individual sub-processes.

**Processes**:
1. **Process 1.0: Student Module**
- Submits assignments, views grades/feedback.
2. **Process 2.0: Faculty Module**
- Uploads assignments, evaluates submissions, provides grades/feedback.
3. **Process 3.0: Admin Module**
- Manages users and system data.

**Data Stores**:
1. **D1: Assignment Data**: Stores details of assignments.
2. **D2: Submission Data**: Stores student submissions and their statuses.
3. **D3: User Data**: Stores user details (Students, Faculty, Admin).

---

### **First-Level DFD Representation**:

```
+-------------------+
| Student |
+-------------------+
| Submit, View +------------------+
+-------------------> | 1.0 Student |
| Module |
+--------+---------+
|
| Store/View
v
+-----------------------+
| D1: Submission Data |
+-----------------------+
|
+-------------------+ |<--------------+
| Faculty | | |
+-------------------+ | |
| Evaluate Assignments v |
+---------------------------> | 2.0 Faculty |
| Module |
+--------+-------+
|
|
+--------------+------------+
| |
+--------------------------+ +--------------------+
| D2: Assignment Feedback | | D3: Assignment Data|
+--------------------------+ +--------------------+
```

---

### **2. (b) GANTT Chart for the Development of OASS**

**Assumptions for Development Phases**:

1. **Requirement Analysis**: Understanding system requirements.
2. **Design**: Creating the architecture, DFDs, and ERD.
3. **Development**: Writing the code for various modules.
4. **Testing**: Testing individual modules and system integration.
5. **Deployment**: Deploying the system for users.

---

### GANTT Chart Representation:

| **Task** | Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Week 6 |

|--------------------------|--------|--------|--------|--------|--------|--------|
| **Requirement Analysis** | ██████ | | | | | |
| **System Design** | | ██████ | ██████ | | | |
| **Module Development** | | | ██████ | ██████ | | |
| **Integration Testing** | | | | ██████ | ██████ | |
| **Deployment** | | | | | ██████ | ██████ |

- **Week 1-2**: Requirement gathering and design preparation.

- **Week 3-4**: Module coding and functionality development.
- **Week 5**: System integration and testing.
- **Week 6**: Deployment and final testing.

1.1. (a) Develop SRS for Online Assignment Submission System (OASS) for students of various
courses of university. SRS should be in IEEE format. Make necessary assumptions.

### **Software Requirements Specification (SRS) for Online Assignment Submission System (OASS)**

#### **1. Introduction**

1.1 **Purpose**
The purpose of this Software Requirements Specification (SRS) document is to define the
functional, non-functional, and system requirements for the Online Assignment Submission System
(OASS). The system is designed for university students and faculty to manage the submission,
evaluation, and tracking of assignments for various courses.

1.2 **Scope**
The OASS is an online platform that allows:
- **Students** to upload their assignments, track submission status, and view feedback/grades.
- **Faculty** to upload assignments, evaluate submissions, and provide feedback/grades.
- **Admins** to manage users, courses, and system configurations.

This system will improve the efficiency of assignment handling, reduce manual errors, and provide
a centralized platform for submission and evaluation.

1.3 **Definitions, Acronyms, and Abbreviations**

- **OASS**: Online Assignment Submission System.
- **SRS**: Software Requirements Specification.
- **Admin**: System administrator responsible for managing users and courses.
- **Faculty**: Teachers who upload assignments and evaluate submissions.
- **Students**: Users who submit assignments and receive feedback/grades.

1.4 **References**
- IEEE Std 830-1998: Recommended Practice for Software Requirements Specifications.
- Assumed university guidelines for assignment submission.

1.5 **Overview**
This document provides a detailed description of system functionalities, user interactions,
performance requirements, design constraints, and assumptions for the development of OASS.

---

#### **2. Overall Description**

2.1 **Product Perspective**

The OASS will be a web-based application accessible to students, faculty, and administrators. It
will consist of the following modules:
- **Student Module**: Allows students to submit assignments, view grades, and feedback.
- **Faculty Module**: Allows faculty to upload assignments, evaluate submissions, and provide
grades.
- **Admin Module**: Enables the admin to manage users, courses, and system data.

2.2 **Product Functions**

- **Student**:
- View assigned tasks and deadlines.
- Upload completed assignments.
- Check submission status, grades, and faculty feedback.
- **Faculty**:
- Create and upload assignments.
- Access and evaluate student submissions.
- Provide grades and feedback.
- **Admin**:
- Add, update, and remove students and faculty.
- Manage course and assignment information.

2.3 **User Characteristics**

- **Students**: Basic knowledge of web navigation and university assignment requirements.
- **Faculty**: Familiarity with web-based platforms and grading systems.
- **Admin**: Knowledge of system administration and course management.

2.4 **Constraints**
- System must be accessible 24/7 with minimal downtime.
- The application will support a maximum of 500 concurrent users initially.
- Adheres to university assignment submission policies.

2.5 **Assumptions and Dependencies**

- All users have access to the internet and a modern web browser.
- Assignments will be in standard digital formats like PDF, DOC, or TXT.
- The system will be deployed on university servers.

---

#### **3. Specific Requirements**

3.1 **Functional Requirements**

1. **Student Functionalities**:
- Students must log in using their university credentials.
- Students can view assigned tasks with submission deadlines.
- Students can upload assignments and verify successful uploads.
- Students can view grades and feedback for submitted assignments.

2. **Faculty Functionalities**:
- Faculty must log in using their university credentials.
- Faculty can upload assignments with deadlines and instructions.
- Faculty can access and evaluate submitted assignments.
- Faculty can provide grades and feedback.

3. **Admin Functionalities**:
- Admins can manage user accounts (add/update/delete students and faculty).
- Admins can manage courses and their associated assignments.

3.2 **Non-Functional Requirements**

1. **Performance Requirements**:
- The system should respond to user requests within 2 seconds under normal load.
- The system should support 500 concurrent users.

2. **Security Requirements**:
- User credentials must be securely stored and verified using encryption.
- Role-based access control to prevent unauthorized access to data.

3. **Usability Requirements**:
- The user interface should be intuitive and user-friendly.
- The system must provide help documentation for new users.

4. **Availability**:
- The system must be available 99.5% of the time.

3.3 **External Interface Requirements**

1. **User Interface**:
- Web-based interface compatible with desktops, laptops, and mobile devices.
2. **Hardware Interfaces**:
- The system will run on university servers with standard hardware configurations.
3. **Software Interfaces**:
- Compatible with modern browsers (e.g., Chrome, Firefox).

3.4 **Data Requirements**

- User data (e.g., login credentials, profiles).
- Assignment data (e.g., titles, descriptions, deadlines).
- Submission data (e.g., uploaded files, timestamps).

---

#### **4. Appendices**

- **A. Glossary**:
- **Assignment**: A task assigned by faculty to students.
- **Submission**: A file uploaded by a student in response to an assignment.

- **B. Diagrams**:
ERD and DFD (Zero and First-Level) can be added here.