EXPERIMENT-

01
Identifying the Requirements from Problem
Statement

Examination portal
When defining the characteristics of requirements for an examination portal, it's
important to focus on how these requirements should be designed and
implemented to ensure the system is effective, secure, and user-friendly. Here
are some key characteristics:

Functional Requirements
1- User Management
 User Registration and Login: Secure user registration and
authentication processes, including support for multi-factor authentication.
 Role Management: Different roles (e.g., administrators, instructors,
students) with specific permissions and access rights.
 Profile Management: Users should be able to manage their profiles,
including updating personal information and managing passwords.
2- Exam Creation and Management
 Question Bank: Functionality to create, edit, and organize questions
into categories. Support for various question types (e.g., multiple-
choice, true/false, short answer).
 Exam Configuration: Define exam parameters such as duration, start
and end dates, and type (e.g., timed, open-book).
 Scheduling: Ability to schedule exams and manage exam availability.

3- Exam Delivery
 User Interface: Intuitive interface for taking exams, with features such as
navigation between questions, saving progress, and a review mechanism.
 Adaptive Testing: Capability for adaptive exams that adjust difficulty based on
user responses (if applicable).
4- Grading and Feedback

 Automatic Grading: For objective questions, with instant feedback to users.

 Manual Grading: Support for grading subjective answers by instructors, with options
for comments and detailed feedback.
 Grade Management: Functionality for managing and recording grades, including
detailed reports and analytics.

5- Reporting and Analytics

 Performance Reports: Generate reports on individual and group performance,
including statistical analysis.
 Data Export: Ability to export data and reports in various formats (e.g., CSV,
PDF).
6- Notifications and Alerts
 Exam Reminders: Automatic notifications for upcoming exams, deadlines, and
results.
 System Alerts: Inform users about system updates, maintenance, or issues.

Non-Functional Requirements
1. Usability
 User Experience: Easy-to-use interface with clear instructions and
intuitive navigation.
 Accessibility: Compliance with accessibility standards (e.g., WCAG)
to ensure usability for all users.
2. Performance
 Response Time: Quick response times for user interactions and
exam submissions.
 Scalability: Ability to handle varying numbers of concurrent users
and exams without performance degradation.
3. Security
 Data Protection: Encryption of sensitive data, including exam
content and personal information.
 Access Control: Proper access control mechanisms to prevent
unauthorized access to exams and user data.
 Audit Logs: Maintain logs of user activities and system changes for
auditing and security purposes.
4. Reliability
 Availability: High availability with minimal downtime, including
backup and disaster recovery plans.
 Error Handling: Robust error handling and reporting mechanisms
to manage and resolve issues effectively.
 5. Maintainability
 Documentation: Comprehensive documentation for users,
administrators, and developers.
 Support: Availability of technical support and user assistance for
troubleshooting and guidance.

EXPERIMENT- 02
Estimation Of Project Metrics

When estimating project metrics for an examination portal, you need to consider
various factors to ensure the system's effectiveness and reliability. Here are
some key metrics and considerations for such a project:
1. User Metrics
 Number of Users: Estimate the number of students, teachers, and
administrators who will use the system.
 User Growth Rate: Anticipate how user numbers will grow over time to
plan for scalability.
2. Performance Metrics
 Response Time: Measure how quickly the system responds to user
actions (e.g., loading pages, submitting exams).
 Throughput: The number of transactions the system can handle per unit
of time.
 Scalability: Ability to handle increased load without performance
degradation.
3. Reliability Metrics
 System Uptime: Percentage of time the system is operational and
accessible.
 Error Rate: Frequency of errors or failures in the system.
 Recovery Time: Time required to recover from a failure or crash.
4. Functionality Metrics
  Feature Completeness: Percentage of planned features that are fully
implemented.
 Bug Rate: Number of bugs or issues found per unit of functionality or
time.
5. Security Metrics
 Vulnerability Count: Number of security vulnerabilities identified.
 Incident Response Time: Time taken to address and resolve security
incidents.
 Compliance: Adherence to data protection regulations (e.g., GDPR,
FERPA)

Cocomo Model for Examination Portal

Using the COCOMO model to estimate the effort, cost, and schedule for an
examination portal involves several key steps. Below is a detailed process using
the Basic COCOMO model, but I will also briefly touch on Intermediate and
Detailed COCOMO models for completeness.
1. Estimate Project Size
Estimate the size of the project in thousands of Lines of Code (KLOC). If you
don’t have exact data, you might use function points or historical data to
approximate. For this example, let’s assume the project size is 120 KLOC.
2. Classify the Project Type
COCOMO classifies projects into three categories based on complexity:
 Organic: Small, simple projects with a small team and minimal
requirements.
 Semi-Detached: Intermediate complexity with a mix of simple and
complex components.
 Embedded: Highly complex with stringent requirements and constraints.
An examination portal, which involves user management, exam handling, and
possibly integration with other systems, is likely to be classified as Semi-
Detached.
3. Apply Basic COCOMO Formulas
The Basic COCOMO model provides a rough estimate using the following
formulas:
Effort Estimation
Effort(E)=a×(KLOC)b\text{Effort} (E) = a \times (\
text{KLOC})^bEffort(E)=a×(KLOC)b
Where:
 aaa and bbb are constants depending on the project type.
For Semi-Detached projects:
 a=2.5a = 2.5a=2.5
 b=0.38b = 0.38b=0.38
Development Time Estimation
Development Time(D)=2.5×(Effort)0.38\text{Development Time} (D) = 2.5 \
times (\text{Effort})^{0.38}Development Time(D)=2.5×(Effort)0.38
4. Calculate Effort
Using the formula:
E=2.5×(120)0.38E = 2.5 \times (120)^{0.38}E=2.5×(120)0.38
1. Calculate 1200.38120^{0.38}1200.38: 1200.38≈11.39120^{0.38} \
approx 11.391200.38≈11.39
2. Multiply by aaa: E=2.5×11.39≈28.5 person-monthsE = 2.5 \times
11.39 \approx 28.5 \text{ person-months}E=2.5×11.39≈28.5 person-
months
5. Estimate Development Time
Using the effort calculated:
D=2.5×(28.5)0.38D = 2.5 \times (28.5)^{0.38}D=2.5×(28.5)0.38
1. Calculate 28.50.3828.5^{0.38}28.50.38:
28.50.38≈5.4928.5^{0.38} \approx 5.4928.50.38≈5.49
2. Multiply by 2.5: D=2.5×5.49≈13.7 monthsD = 2.5 \times 5.49 \approx
13.7 \text{ months}D=2.5×5.49≈13.7 months
6. Estimate Cost
To estimate the cost, multiply the effort by the average monthly salary of a
software developer. For example, if the average monthly salary is $8,000:
Cost=Effort×Monthly Salary\text{Cost} = \text{Effort} \times \text{Monthly
Salary}Cost=Effort×Monthly Salary Cost=28.5×8000≈$228,000\text{Cost} =
28.5 \times 8000 \approx \$228,000Cost=28.5×8000≈$228,000
Summary Using Basic COCOMO
For a 120 KLOC examination portal classified as Semi-Detached:
1. Effort: Approximately 28.5 person-months.
2. Development Time: Approximately 13.7 months.
3. Cost: Approximately $228,000 (based on an $8,000 average monthly
salary).
Intermediate and Detailed COCOMO Models
For more accuracy, consider using the Intermediate or Detailed COCOMO
models:
  Intermediate COCOMO: Incorporates cost drivers like product attributes,
hardware attributes, personnel attributes, and project attributes. It
provides a more detailed estimate than Basic COCOMO.
 Detailed COCOMO: Includes a more comprehensive set of cost drivers
and factors, offering a very precise estimate. It accounts for various
attributes affecting cost and effort, providing detailed insights into
different phases of development.
These models require additional inputs and factors, such as:
 Product Attributes: Complexity, reliability, and user documentation.
 Hardware Attributes: Constraints and environment.
 Personnel Attributes: Experience and capabilities.
 Project Attributes: Constraints, tools used, and project documentation.
To use these models, you'll need to assess each cost driver and apply their
corresponding multipliers to adjust your effort estimates accordingly.

EXPERIMENT- 03
Modeling UML Use Case Diagrams and
Capturing Use Case Scenarios

Modeling UML Use Case Diagrams and capturing use case scenarios are crucial
steps in designing an examination portal. Use Case Diagrams provide a high-
level view of the system’s functionality from the user’s perspective, while Use
Case Scenarios detail the interactions between users and the system to achieve
specific goals.
1. Modeling UML Use Case Diagrams
Use Case Diagrams help visualize the system's functional requirements and
interactions between different types of users (actors) and the system. Here’s
how you can model Use Case Diagrams for an examination portal:
1.1 Identify Actors
Actors are entities that interact with the system. In an examination portal, typical
actors might include:
  Student: Takes exams, views results, and manages their profile.
 Teacher/Instructor: Creates and manages exams, views student
performance, and provides feedback.
 Administrator: Manages user accounts, oversees system settings, and
performs maintenance tasks.
1.2 Identify Use Cases
Use Cases represent the functionalities or services the system provides to its
users. For an examination portal, common use cases might include:
 Student:
o Register for an exam

o Take an exam

o View exam results

o Update profile information

o Review exam history

 Teacher/Instructor:
o Create a new exam

o Manage existing exams

o Grade exams

o View student performance reports

o Provide feedback to students

 Administrator:
o Create user accounts

o Manage user permissions

o Perform system maintenance

o Generate system reports

1.3 Create the Use Case Diagram

Draw the Use Case Diagram with the following steps:
1. Draw Actors: Represent each actor with a stick figure or labeled icon on
the diagram.
2. Draw Use Cases: Use ovals to represent each use case.
3. Connect Actors to Use Cases: Use lines to connect actors to the use
cases they interact with.
 4. Organize Use Cases: Group related use cases into systems or
subsystems if necessary, and use system boundaries to define the scope
of the portal.
Example Diagram:
 Actors: Student, Teacher, Administrator
 Use Cases:
o Student: Register for an exam, Take an exam, View exam results

o Teacher: Create an exam, Grade exams, Provide feedback

o Administrator: Manage users, Perform maintenance

Diagram Layout:
[Student] ---- (Register for an exam)
|
---- (Take an exam)
|
---- (View exam results)

[Teacher] ---- (Create an exam)

|
---- (Grade exams)
|
---- (Provide feedback)

[Administrator] ---- (Manage users)

|
---- (Perform maintenance)
2. Capturing Use Case Scenarios
Use Case Scenarios detail the steps involved in each use case and describe the
interaction between the actor and the system. They include primary flows
(normal scenarios) and alternative flows (exceptional or error scenarios).
2.1 Define a Use Case Scenario
For each use case, write a scenario that describes the sequence of interactions.
Use the following template:
1. Use Case Name: The name of the use case.
2. Actor: The primary actor involved.
 3. Preconditions: Conditions that must be met before the use case starts.
4. Postconditions: The state of the system after the use case completes.
5. Main Flow: The primary sequence of steps taken to achieve the goal.
6. Alternative Flows: Variations or error conditions that can occur.
2.2 Example Use Case Scenario
Use Case: Register for an Exam
 Actor: Student
 Preconditions: Student must be logged in to the portal.
 Postconditions: Student is registered for the exam, and confirmation is
sent.
 Main Flow:
1. Student logs in to the examination portal.
2. Student navigates to the exam registration section.
3. Student selects the desired exam from the list.
4. Student confirms the registration.
5. System processes the registration and updates the student’s exam
schedule.
6. System displays a confirmation message.
7. System sends a confirmation email to the student.
 Alternative Flows:
o Invalid Exam Selection:

1. If the selected exam is full, the system displays an error

message.
2. Student selects another exam or waits for availability.
o Login Failure:

1. If the student is not logged in, redirect to the login page.

2. Student logs in and retries registration.
Conclusion
Modeling UML Use Case Diagrams and capturing use case scenarios are essential
for clearly understanding and documenting the requirements and functionality of
an examination portal. Use Case Diagrams provide a visual representation of the
interactions between users and the system, while Use Case Scenarios offer
detailed descriptions of the steps involved in each use case, including main and
alternative flows. This approach helps ensure that all functional requirements are
captured and provides a solid foundation for further design and development
phase
In UML (Unified Modeling Language), a generalization relationship is used to
model inheritance between classes or actors, showing that one class or actor
(the child or subclass) inherits the properties and behaviors of another class or
actor (the parent or superclass). For an examination portal, generalization can
help simplify the model by showing commonalities and variations between
different types of users or components.
Here’s how you might use generalization relationships in an examination portal:
1. Generalization in Actor Modeling
In an examination portal, different types of users may share common
functionalities but also have specific roles and responsibilities. Generalization
helps represent these shared and specific aspects.
Example:
 Actor: User
o Generalizes to:

 Student
 Teacher
 Administrator
Explanation:
 User is a general actor that represents common functionalities such as
logging in and updating a profile.
 Student, Teacher, and Administrator are specific actors that inherit
these common functionalities from User and add their own specific
functionalities.
Diagram:

+----------------+
| User |
+----------------+
/\
/ \
/ \
+--------+ +---------+ +-------------+
| Student | | Teacher | | Administrator |
+--------+ +---------+ +-------------+
2. Generalization in Use Case Modeling
In Use Case Diagrams, generalization can show that different use cases share
common behavior or functionality.
Example:
 Use Case: Manage Account
o Generalizes to:

 Update Profile
 Change Password
Explanation:
 Manage Account is a general use case that covers the common actions
of managing an account.
 Update Profile and Change Password are specific use cases that
inherit from Manage Account.
Diagram:
+----------------+
| Manage Account |
+----------------+
/\
/ \
/ \
+---------------+ +-----------------+
| Update Profile| | Change Password |
+---------------+ +-----------------+
3. Generalization in Class Modeling
In class diagrams, generalization is used to show that one class (subclass)
inherits attributes and operations from another class (superclass).
Example:
 Class: User
o Generalizes to:

 Student
 Teacher
 Administrator
Explanation:
 User is a base class with common attributes like username and password
and methods like login() and logout().
  Student, Teacher, and Administrator inherit these attributes and
methods from User and add their own specific attributes and methods.
Diagram:
+------------------------+
| User |
+------------------------+
| - username: String |
| - password: String |
+------------------------+
| + login(): void |
| + logout(): void |
+------------------------+
/ | \
/ | \
/ | \
+---------+ +---------+ +-------------+
| Student | | Teacher | | Administrator |
+---------+ +---------+ +-------------+
| - studentID: String | | - teacherID: String | | - adminID: String |
| + register(): void | | + gradeExam(): void | | + manageSystem(): void |
+---------------------+ +---------------------+ +------------------------+
Summary
Generalization relationships in an examination portal model allow you to:
1. Simplify the Model: By defining common behavior in a general class or
actor and inheriting it in specific subclasses or specialized actors, you can
avoid redundancy and simplify the design.
2. Show Commonality and Specialization: Illustrate how different types
of users or components share common features but also have unique
aspects.
3. Facilitate Maintenance and Extension: Changes made to the general
class or actor automatically propagate to all specialized classes or actors,
making the system easier to maintain and extend.
This approach helps in creating a clearer, more organized model of the
examination portal's functionality and user interactions.
EXPERIMENT- 04
E-R Modeling from the Problem
Statements