Project Documentation

Project Title:Internal Assessment System

Submitted to:Ms Jasleen Kaur Mam

Subject:CSC-503 Software Engineering
Course:B.sc(H)Computer Science
Year:2024 (SEM-V)
Sri Guru Tegh Bahadur Khalsa College,
University of Delhi,Delhi-110007
Submitted By:

SAURABH MADAN TARANPREET SINGH

(2022CSC1014) (2022CSC1026)
Internal Assessment (IA) Portal
Development Report
1. Problem Statement
In a rapidly evolving educational environment, the need for a structured and transparent
assessment management system is more crucial than ever. Current manual methods for
handling assignments, tracking submissions, and organizing courses create significant
challenges for both teachers and students, resulting in delays, lost assignments, and limited
visibility into assessment progress.

The Internal Assessment (IA) Portal seeks to address these issues by providing a centralized
platform where teachers can seamlessly create and manage assignments and quizzes, and
students can access, complete, and submit their work. The portal is designed to bring real-time
submission tracking, clear communication of deadlines, and structured course management,
ensuring that both teachers and students are informed and engaged throughout the assessment
process.

Along with that it provide interface for the university/college to create course, student, teachers
and assign courses to them.

2. Process Model
We use a Evolutionary Process Model for our project which mean dividing the project into
smaller independent part and start building it independently then start a new model and
developing that

3. Data Flow Diagram

 Zero Level DFD
  1 Level D-F-D

Generating

DATA DICTIONARY

Student:
 student-ID:char+char+char+digit+digit+digit&(required and unique)

 Name:String (required)

 Email:string,(required , unique)

 Password:Hash Value(Default:”NOT-SET”)

 DOB: YYYY- MM-DD

 Gender:”MALE” OR “FEMALE”

Teacher

 teacher ID:char+char+char+digit+digit+digit&(required and unique)

 Name:String (required)

 Email:string,(required , unique)

 Password:Hash Value(Default:”NOT-SET”)

 DOB: YYYY- MM-DD

 Gender:”MALE” OR “FEMALE”

Course
  course ID:char+char+char+digit+digit+digit&(required and unique)

 Name:String(Required)

course-Allot:

 course-ID:char+char+char+digit+digit+digit&(required and unique)

 user-ID: char+char+char+digit+digit+digit

 Role:Instructor or Student

Assignment

 Assignment-ID:’A’+course ID+:+digit+digit+digit

 Name:String

 created BY:Teacher-ID

 subject Code:course-ID

 end-Date:Date;

 Max Marks:Integer

 Content:String

 assignment Path:path

IA Report: Excel or PDF File

Submission

 submissionID:’S’+courseID+:+digit+digit+digit;

 assignmentID:assignmentid

 submissionerID:studentID

 submissionDate:Date+time;

 Marks:integer

 submission content:String

 submissionPath:path of submitted file

 USE CASES
Use cases specify the functionality of a system by specifying the behavior of
the system, captured as interactions of the users with the system.

For University
1.Creating Teacher,Student,Course&Allotting Course

Primary Actor:University

Precondition:Administrator logged in

Main Flow:(Teacher and Student Creation)

1. Admin login

2. Go to teacher or student creation

3. Enter Details

4. Submit The Details

Main Success:

 Teacher,Student is created and they receive a email with their Unique ID

Extension Scenario:

 if admin enter wrong password it forward to login page

 Admin misfill the field or the same email id is entered then the system popup with valid
error reason

2.Course Creation

Primary Actor:University

Precondition:Administrator logged in

Main Flow:(Course creation)

1. Admin Login

2. Go to Course Section

3. Enter Course ID and Course Name

 4. Submit

Main Success:

 Course is Created

 Course is previously Created an error occurred

3. Allotting Course

Primary Actor:University

Precondition:Administrator logged in

Main Flow:(Allotting course)

1. Admin Login

2. Go To Course Allot Section

3. Enter User ID ,Role Or Fetch to see previous Course

4. Add or Modify Course

5. Submit
For Teachers
1. Teacher Login&Creating Assignment

Main Actor:Teacher

Precondition:Teacher Must Be Logged In

Main Flow

1. The teacher enters credentials and successfully logs into the IA portal.

2. The teacher accesses the assignment section from their dashboard.

3. The teacher clicks on "Create Assignment" to start the assignment creation process.

4. The teacher fills in required fields, including

 Assignment Name
 Subject Code
 Assignment Description
 Deadline (due date for submission)
 Maximum Marks
5. If the assignment requires additional resources, the teacher can upload relevant files
(e.g., PDFs, Word documents, images).

6. The teacher clicks "Upload" to attach the file(s) to the assignment.

7. The teacher clicks "Save" to publish the assignment and system confirms the
assignment is created and made available for students to view and submit.
8. The teacher clicks on a student’s submission to view the uploaded file and other
submission details.
9. The teacher enters a grade (score out of maximum marks) and any feedback comments
for the student.
10. The teacher clicks "Submit" to save the grade and feedback.
Extension Scenario:

 If the teacher enters incorrect credentials, the system displays an error message and
requests re-entry.

 If there’s a system error during creation (e.g., database error), the system displays an
error message and prompts the teacher to retry.
For Students
1. Student - View and Submit Assignment

Main Actor:Student

Precondition

 The student must be registered in the system and logged in.

 The student is enrolled in courses that have active assignments.

Main Flow:

1. The student enters their credentials and successfully logs into the IA portal.

2. The student goes to the "Assignments" section from their dashboard, which lists all
assignments for the enrolled courses.
3. The student clicks on a specific assignment to view details, including:

 Assignment Name
 Subject Code
 Description/Instructions
 Deadline
 Maximum Marks
 Any attached files or additional resources uploaded by the teacher
 4. If the teacher has attached any files, the student can download them for reference.

5. The student completes the assignment based on the provided instructions.

6. The student clicks "Submit" and uploads their completed work (e.g., PDF, Word
document, image).
7. The student may add any additional comments for the teacher if needed.
8. The system confirms that the assignment has been successfully submitted.
9. After the teacher grades the assignment, the student can return to the assignment to
view feedback and their grade.

Extension Scenario:
 The system either restricts submission (if late submissions are not allowed) or flags the
submission as late.
 The student is notified of any penalties or consequences for late submission.
 If there’s an error while uploading the file, the system displays an error message and
prompts the student to retry.
 If the file size exceeds the allowed limit, the system notifies the student to reduce the file
size before uploading.
 SRS Document
1. Introduction
1.1 Purpose
The purpose of this document is to provide a comprehensive description of the Internal
Assessment (IA) Portal. This portal is designed for academic institutions to facilitate the
process of creating, managing, and submitting assessments (assignments and other resources)
within a centralized platform. The portal aims to streamline communication between teachers
and students, enabling efficient submission tracking and grading.

1.2 Scope
The IA Portal will:
- Allow teachers to create assignments and resources for students.
- Enable students to view assigned assessments and submit their work.
- Manual grading by teachers and generating automatic IA Report.
- Provide a dashboard for teachers and students to view the status of assessments.
- Allow university to manage course enrollments,teachers and Students.
- Maintain a secure database of assignments, submissions, and results.

1.3 Definitions, Acronyms, and Abbreviations

- IA: Internal Assessment
- Assignment: Academic work assigned to students for completion.
- Quiz: A test with questions for assessing student knowledge, which can be graded
automatically.
- Course: A subject or class that students are enrolled in and linked to assessments.
- Teacher: A faculty member responsible for creating and managing assessments.
- Student: A user of the portal who completes and submits assignments and quizzes.

1.4 References
- Academic assessment policies.
- Database schema for the IA Portal (MongoDB or equivalent).
- Data flow diagrams for system architecture.
2. Overall Description
2.1 Product Perspective
The IA Portal is a web-based application intended to be used by academic institutions. It will
integrate with existing student information systems to provide a smooth experience in
managing assessments. Teachers can assign tasks, and students can view and submit them
within the portal. The portal will store assignment and submission data, allowing for easy access
to historical information and records.

2.2 Product Functions

Teacher Functions:
 Create Assignment and grade them.
 Set deadlines and maximum marks for each assessment.
 View and track student submissions.
 Grade submissions manually and update the system with scores.
Student Functions:
 View assigned assessments for enrolled courses.
 Submit assignments and quizzes before deadlines.
 View submission status and grades once graded.
University Functions:
 Manage teacher and student accounts.
 Oversee course assignments and enrollments.
 Maintain system logs and backup data.

2.3 User Characteristics

 Teachers: Experienced with managing student assessments and familiar with using web
applications.
 Students: Regularly use web applications, able to upload files, and raise query
 University: Experienced with managing users and troubleshooting technical issues.
2.4 Constraints
 The portal must be accessible via web browsers.
 The database should maintain student privacy and data security.
 Response time for viewing or submitting assessments should be minimal.
3. Specific Requirements
3.1 External Interface Requirements

3.1.1 User Interfaces

 Login Screen: Allows users (students, teachers, admins) to log in securely.

 Dashboard: Displays an overview based on user type (e.g., assignments for students,
submission tracking for teachers).
 Assignment Creation & Submission Pages: Allows teachers to create assignments
and students to submit them.
 Grading Interface: Allows teachers to grade assignments, add comments, and provide
feedback.
 Admin Panel: For university administration to manage users, courses, and allotting
course.

3.1.2 Hardware Interfaces

 The IA Portal can be accessed from any device with compatible browser
 The User should have a good internet connection with minimum basic requirement(
 1GB of RAM,8GB of Storage)

3.1.3 Software Interfaces

 Database: MongoDB is used to store data on users, assignments, submissions, and

grades.
 Web Server: Express is used for handling requests and performing operations.

 Authentication: JWT (JSON Web Tokens) for securing user sessions.

3.1.4 Communication Interfaces

 HTTP/HTTPS Protocols: Used for secure and fast communication between the client
and server.
 SMTP: Configured to send notifications about deadlines, submissions, and feedback.

3.2 Functional Requirements

3.2.1 Mode 1: Student Mode

 Students should be able to view a list of assignments for their enrolled courses.
 Students should be able to submit assignments by uploading files or entering text
responses.
 Students should be able to view submission status, feedback, and grades.
 Students should be able to view announcements or updates from teachers.
3.2.2 Mode 2: Teacher Mode

 Teachers should be able to create assignments by specifying details like title, deadline,
max marks, and additional resources.
 Teachers should be able to view submissions from students and mark them as graded or
pending.
 Teachers should be able to assign grades and feedback to each submission.
 Teachers should be able to download a report of assignment submissions and grades.

3.2.3 Mode 3: Admin Mode (University)

 Admins should be able to manage user accounts,course (add, delete, or modify student
and teacher accounts).
 Admins should be able to oversee course enrollments, including adding or removing
students from courses.

3.3 Performance Requirements

 Load Handling: The system should support up to 100 concurrent users without a
noticeable decrease in performance.
 Response Time: Standard actions (viewing an assignment, submitting work) should be
completed within 2 seconds.
 Data Retrieval: Loading an assignment list or submission history should take no more
than 5 seconds for any user.

3.4 Design Constraints

 Browser Compatibility: The portal should work on all major browsers (Chrome,
Firefox, Edge, Safari).
 Database Choice: MongoDB is preferred for handling assignment, submission, and
user data.
 Security Standards: Compliance with data privacy regulations, ensuring secure
handling of student and assignment data.

3.5 Attributes

 Reliability: The system should maintain 99.9% uptime, with regular backups to
prevent data loss.
 Maintainability: The codebases should be modular, enabling updates or fixes with
minimal disruption.
 Usability: The portal should have an intuitive design, with clear navigation and
accessible help documentation.
 Scalability: The system should be able to expand to accommodate more users or
courses with minimal configuration changes.
3.6 Other Requirements

 Backup and Disaster Recovery: Weekly automated backups of the database to

prevent data loss.
 User Support: An integrated help desk or support system for troubleshooting common
issues.
 Audit Logs: Maintain logs of all user actions for monitoring and compliance purposes.
 Accessibility: Compliance with web accessibility standards (e.g., WCAG) to support
users with
 Function Point Calculation
Function Point (FP) is a standardized unit of measure for assessing the
functionality of a software system. It focuses on the software's deliverables from a
user's perspective and is widely used for software development effort estimation,
productivity analysis, and benchmarking.

Information domain values are defined in the following manner:

 External Inputs (EIs): Data or control inputs from users or other systems that
update internal files.

 External Outputs (EOs): Derived information sent to users like reports or

screens.

 External Inquiries (EQs): Online inputs that trigger immediate responses, often
from internal files.

 Internal Logical Files (ILFs): Grouped data stored within the application.

 External Interface Files (EIFs): External data groups used by the application but
not stored within it

Size Estimation of project

 Total external inputs = 7(Creating Student,Teacher,Course,Alloting

Course,Creating Assignment&Submission,Grading Marks)
 Total external outputs = 3(Grades,Assignment,Submission)

 Total logical internal files = 1

 Total external inquiries = 6

 Total external interface files = 1

Function Point =UFP x VAF = Count Total * (0.65 + 0.01 * Σ𝒇𝒊)

(Assuming Simple weighting factor for user input,outputs and inquiries and
Average Complexity for internal files and external interface)

Computing Unadjusted Function Point

UFP(Total)={7*3}+{3*4}+{1*10}+{6*3}+{1*7}=59

Computing Variable Adjusting Factor

1. Data Communications – 3
2. Distributed Data Processing - 2
3. Performance - 4
4. Heavily Used Configuration - 3
5. Transaction Rate - 3
6. Online Data Entry - 4
7. End-User Efficiency - 3
8. Online Update - 4
9. Complex Processing - 3
10. Reusability - 2
11. Installation Ease - 1
12. Operational Ease - 3
13. Multiple Sites - 2
14. Facilitate Change – 3
0.65+(0.01×40)=1.05

Adjusted Factor Point is =59*1.05

Adjusted Factor Point is =61.95

 Effort&Cost Calculation
Effort Calculation

Effort in software development refers to the amount of work or time required

to complete a task or project. It is typically measured in person-hours, person-days,
or person-months and is used to estimate the resources needed to design, develop,
test, and deploy a system or application.

Formula

Effort (person-hours)= Function point(FP) x Productivity rate

The productivity rate in software development refers to the average number of

person-hours required to complete one function point (FP) in a project. It is a
measure of how efficient the development process is in terms of effort required to
implement a specific functionality.

We assume productivity rate of 7 Person-Hours per FP for our project.This is acceptable

in all kind of Web application with simple interface requirement.

Therefore,

Effort(Person-In-hour) =61.95*7
=433.65 hours
~435 hours

Cost Calculation

The total cost of the project can be calculated by multiplying the total
Person-Hours by the hourly rate.

Total Cost=Total Effort (in Person-Hours)×Hourly Rate

We assume hourly rate as ₹200

Therefore,

Total Cost=435*200
=₹87,000
Therefore

Total Person hours required to build the project is 435 Hours

Total Cost required to build the project is ₹87,000
 Risk Table
Risk Category Probability Impact RMMM
Database downtime Technology 70% Critical Use a cloud-based database (e.g.,
leading to data MongoDB Atlas) with backups
unavailability and failover capabilities.

Unauthorized Security 60% Critical Implement strong authentication

access to sensitive
user data.

Bugs in assignment Functionality 40% Marginal Conduct thorough unit and

submission or integration testing before
retrieval deployment
functionality.

Slow response time Performance 50% Catastrophic Ensure the portal is responsive
due to high and cross-browser tested.
concurrent user
load.
 TESTING
Path Testing is use for our project
Path Testing :It is a vital software testing technique that ensures all possible execution
paths within a module are tested at least once. By focusing on achieving complete code
and branch coverage, path testing helps identify logical errors, unreachable code, or
edge-case failures in software systems.

Path Testing For Univ Module

Objective:

1. Validate that the system handles every supported operation (AddCourse,

AddTeacher,&Students,AllotCourse ) correctly.
2. Ensure proper error handling for invalid inputs or operations.
3. Verify database interactions for adding or modifying data.
4. Confirm the reliability of conditional flows and decision points

Control Flow Analysis:

1. Start: The system receives the user's operation type.

2. Decision: The operation type is evaluated
(AddCourse,AddTeacher,&Students,
AllotCourse or Invalid).
3. Processing: Validation of inputs and database updates occur for valid
operations.
4. Output: The system provides success or error feedback.
5. End: The process concludes.
Control Flow Diagram
M1

M2

M3 M4 M5

M6 M7 M8

M9

M1:Start M6:Validation of Details of Teacher&Student

M2:Authenticate M7:Validation of Allotted courses
M3:Create Teachers M8:Validation of Courses
M4:Allot Courses M9:Success&Exit
M5:Create Courses
McCabe Cyclomatic Complexity (CC) is a software metric used to measure the
complexity of a program's control flow. It is based on the structure of the program
and calculates the number of independent paths through the source code.

Formula:
Complexity (CC)Cyclomatic Complexity (CC)=E−N+2P
Where:
 E = Number of Edges in the control flow graph.
 N = Number of Nodes in the control flow graph.
 P = Number of connected components (typically 1 for a single program).
In your case:
CC=10−9+2=3
It Signifies
Independent Paths:
 A CC value of 3 means there are three independent execution paths in the
code.
 These are the number of unique paths through which the program can execute,
including loops, if-else conditions, and switches.
Test Cases Required:
 Cyclomatic Complexity directly correlates to the minimum number of test
cases required to achieve full branch coverage (testing all decision points in
the code).
 For CC = 3, at least 3 test cases are required to ensure all paths are executed
during testing.
Code Complexity:
 Low Complexity: A value of 3 indicates that the code is relatively simple and
maintainable.
 Generally:
 CC ≤ 10: Low complexity, easier to test and maintain.
 CC > 10: Increasing complexity, may need refactoring.
 CC > 20: High complexity, likely to be error-prone and hard to maintain.
 Implications for Maintenance:
 A CC value of 3 suggests the code is not overly complex and should be easier to
debug, modify, and extend in the future.