MCS -213
Software Engineering
ues-1Assume that you are assigned responsibility………………………………………………
Q
………………………………………………………………needs to be generated.
ns. 1 (a)For developing the Online Admit Card GenerationSystem (OACGS), anAgile SDLC
A
paradigmwould be the most suitable, though we couldalso explore a hybrid approach or
propose a new paradigm based on the specific requirements of this project. Let me explain why
Agile would fit, and then propose a custom SDLC paradigm tailored to OACGS.
1. Agile SDLC Paradigm
Why Agile?
● Incremental Delivery: Agile allows for step-by-stepdelivery of key modules like
registration, validation, and admit card generation.
● Flexibility & Feedback: Iterative sprints enable quickadjustments based on student or
admin feedback, ideal for a dynamic system like OACGS.
● Cross-platform Compatibility: Early testing on bothPC and mobile ensures a
seamless experience.
● Risk Management: Security and functionality are testedincrementally, reducing overall
risk.
Agile Workflow:
D
● evelopment happens insprintswith continuousfeedback.
● Early deliveryof working parts (e.g., student registration)while refining others in later
sprints.
2. Proposed SDLC Paradigm: Adaptive Modular Development (AMD)
MD is a new approach tailored for systems like OACGS, which deal with sensitive data and
A
must run on multiple platforms.
Key Characteristics:
● M
odular Focus: Independent modules (e.g., Registration, Admit Card Generation) that
can be updated without disrupting the whole system.
● A daptive Cycles: No fixed sprints—modules are continuously adjusted based on
immediate needs.
● Cross-platform First: Ensures compatibility with bothPC and mobile from the start.
● Real-time Feedback: Continuous feedback loop duringmodule development.
● Security-First: Each module undergoes security testingbefore integration.
Justification:
S
● calability: New features can be added easily throughmodular development.
● Quick Adaptation: AMD allows rapid changes, idealfor handling dynamic data like
exam schedules or new course codes.
● Cross-platform Compatibility: Built-in from the startto avoid later adjustments.
Conclusion:
gileoffers flexibility and iterative delivery, whilethe proposedAMDparadigm is better suited
A
for projects like OACGS, which need modularity, security, and real-time adaptability. Both
approaches are viable, but AMD could provide even more efficiency for a cross-platform,
dynamic system.
Ans. 1 (b) Listing the functional and non-functional requirements:.
Functional Requirements:
1. User Authentication:
○ Students must log in using their university credentials (e.g., student ID and
password).
○ Admins and examination staff will have separate logins for managing the system.
2. Examination Form Submission:
○ Students must fill out an online form with personal details (name, address,
Aadhaar number) and upload a color image.
○ Students select courses for which they are eligible to appear for exams.
3. Data Validation:
○ The system validates the Aadhaar number and other details against the
university’s records.
○ Courses, exam centers, and schedules must be cross-checked with the database
for accuracy.
4. Admit Card Generation:
○ Generates admit cards in PDF format with the student's information, color image,
exam center details, and exam schedule.
○ Each admit card includes a unique QR code for verification.
5. Notification System:
○ Automated email and SMS notifications are sent to students when the admit card
is ready, including a download link.
6. Admin Dashboard:
○ Admins can view, edit, and approve examination data, manage students, and
regenerate admit cards if needed.
○ Examination staff can manage exam center information and schedules.
Non-Functional Requirements:
1. Performance:
○ The system must handle multiple concurrent users (students, admins) without
performance degradation, especially during exam season.
○ It should quickly generate and provide access to admit cards (within seconds
after form submission).
2. Scalability:
○ The system should be able to scale as the number of students or exams
increases, especially during peak periods like exam registration.
3. Security:
○ Sensitive data (e.g., Aadhaar number, personal details) must be encrypted both
in transit (SSL/HTTPS) and at rest.
○ Two-factor authentication (2FA) for admin and examination staff.
4. Cross-platform Compatibility:
○ The system must be compatible across different web browsers (Chrome, Firefox,
Safari) and platforms (Windows, macOS, Android, iOS).
5. Data Privacy:
○ The system must comply with local data protection regulations (such as India’s
Aadhaar Data Protection Act or GDPR for international students).
Ans.1(C) Estimate cost:
stimating the cost of developing the Online Admit Card Generation System (OACGS)
E
depends on various factors, such as development time, team size, complexity, technology stack,
and infrastructure. Here's a breakdown to help estimate the cost:
1. Development Team
The following are the adjusted hourly rates and total costs for the development team:
Role Hourly Rate (INR) Hours (Estimation) Total Cost (INR)
Project Manager 875 - 1,375 120 1,05,000 - 1,65,000
UI/UX Designer 525 - 875 100 52,500 - 87,500
Front-end Developer 700 - 1,050 200 1,40,000 - 2,10,000
Back-end Developer 875 - 1,225 250 2,18,750 - 3,06,250
Mobile App Developer 700 - 1,050 200 1,40,000 - 2,10,000
Database Admin 875 - 1,225 100 87,500 - 1,22,500
QA Engineer 525 - 875 150 78,750 - 1,31,250
Security Specialist 1,050 - 1,400 80 84,000 - 1,12,000
DevOps Engineer 875 - 1,225 100 87,500 - 1,22,500
otal Estimated Team Cost: 9,94,000 - 13,66,000
T
(Assumes a mid-range project duration of 3-5 months with multiple team members working in
parallel)
2. Infrastructure Costs
This section remains the same as it's based on typical cloud services and infrastructure costs:
Infrastructure Item Cost (Monthly) Duration Total Cost (INR)
( Months)
loud Hosting (AWS, Azure,
C 15,000- 40,000 3-5 45,000 - 200000
etc.)
Database (Managed Service) 7,500 - 22,500 3-5 22,500- 112500
SSL Certificates 7,500 1 (annually) 7,500
Domain Registration 750 - 2,500 1 (annually) 750 - 2,500
Backup and Security Services 7,500 - 15,000 3-5 22,500 - 75,000
otal Infrastructure Cost: 98,250 - 3,97,500 rupees.
T
(Assumes scalable cloud infrastructure with managed database services and security).
3. Additional Costs
Other factors that influence the cost:
● M aintenance (Post-launch support): 75,000 - 2,25,000 per month (ongoing, for fixing
bugs, adding new features).
● Third-party API integrations (e.g., for SMS, email notifications): 0.50 - 3 per
notification, depending on the number of students.
● Software Licenses (if applicable):Any paid libraries or software that are required.
4. Total Estimated Cost
By combining development, infrastructure, and additional costs:
● evelopment Costs (Team): 9,94,000 - 13,66,000
D
● Infrastructure Costs: 98,250 - 3,97,500
● Maintenance (first 3-6 months): 2,25,000 - 6,75,000
● API and Software Costs: 37,500 - 1,50,000
otal Estimated Cost (Initial Development + Infrastructure):
T
13,54,750 - 25,88,500
Summary:
L
● ow-end Estimate: 13,54,750 rupees
● High-end Estimate: 25,88,500 rupees
his estimate includes development, testing, infrastructure, security, and initial maintenance.
T
The final cost will depend on the specific project scope, team location, and the complexity of the
system.
Ans.1(D) Estimate effort:
To estimate the effort required for developing theOnline Admit Card Generation
ystem (OACGS), we can break it down by key modulesand consider time for development,
S
testing, and deployment. The estimation is based on the complexity of each module and an
average developer velocity. Here’s a rough estimation:
1. Project Planning & Requirements Analysis
● Effort: 2–3 weeks
○ Gathering detailed requirements, setting up the team, creating technical
documents.
2. User Authentication
● Effort: 1–2 weeks
○ Implement login functionality, role-based access control, and security
mechanisms.
3. Examination Form & Data Validation
● Effort: 3–4 weeks
○ Form design, real-time validation (Aadhaar, course eligibility), file upload for
student images.
4. Admit Card Generation (PDF)
● Effort: 2–3 weeks
○ Logic for generating dynamic admit cards, handling various data fields, image
integration, and PDF creation.
5. Notification System
● Effort: 1–2 weeks
○ Automated email and SMS notifications for students.
6. Admin Panel
● Effort: 2–3 weeks
○ Create a dashboard for staff to manage students, generate reports, and reissue
admit cards.
7. Security Implementation
● Effort: 1–2 weeks
○ SSL integration, encryption of sensitive data, and user session management.
8. Cross-platform Design
● Effort: 2–3 weeks
○ Responsive UI design for both mobile and PC platforms.
9. Testing (Unit, Integration, Security)
● Effort: 3–4 weeks
○ Testing functionality, security protocols, cross-platform usability, and stress
testing.
10. Deployment & Maintenance
● Effort: 1–2 weeks
○ Server setup, database configuration, initial deployment, and post-deployment
monitoring.
Total Estimated Effort: 16–22 weeks (approximately 4–6 months)
● T his estimate assumes a team of 4–6 developers, including roles like front-end
developers, back-end developers, testers, and project managers.
● Parallel development and Agile sprints can help reduce the overall timeline.
ns.1(E) Software Requirements
A Specification (SRS)For Online Admit Card
Generation System (OACGS):.
1. Introduction
1.1 Purpose
his SRS outlines the requirements for theOnline Admit Card Generation System (OACGS),
T
which enables students to apply for exams and generate their admit cards online.
1.2 Scope
ACGS allows students to submit exam applications, validates data, and generates admit cards
O
with essential exam information. It works on both PCs and mobile devices.
1.3 Definitions, Acronyms, and Abbreviations
O
● ACGS: Online Admit Card Generation System
● PDF: Portable Document Format
● Aadhaar: Indian unique identification number
1.4 References
● IEEE Std 830-1998: Software Requirements Specification Guide.
1.5 Overview
his document covers system functionality, non-functional requirements, constraints, and
T
assumptions for OACGS. It is for developers, testers, and stakeholders.
2. Overall Description
2.1 Product Perspective
ACGS is a web application for students to generate admit cards. It interacts with university
O
databases and supports mobile and desktop access.
2.2 Product Functions
U
● ser Login: Student authentication.
● Exam Form: Data input and validation.
A
● dmit Card Generation: Automated PDF generation.
● Notifications: Email/SMS alerts.
● Admin Panel: Management by university staff.
2.3 User Characteristics
S
● tudents: Use the system for exam application and admit card generation.
● Admin: Manage data and system operations.
2.4 Constraints
M
● ust ensuredata privacy.
● Must work on bothPCs and mobile devices.
2.5 Assumptions and Dependencies
E
● xistingstudent databasesandexam schedulesareavailable.
● Relies on third-party services forAadhaar validationandnotifications.
3. Specific Requirements
3.1 Functional Requirements
● ser Authentication: Students log in with credentials.
U
● Examination Form: Students fill in and submit theirdetails.
● Admit Card Generation: PDF admit card with all necessary details.
● Data Validation: Validate Aadhaar and course eligibility.
● Notifications: Email and SMS alerts to students.
● Admin Panel: Admins can manage and reissue admit cards.
3.2 Non-Functional Requirements
● erformance: Handle 10,000+ concurrent users.
P
● Security: Encrypt sensitive data (SSL).
● Usability: Intuitive UI for desktop and mobile.
● Availability: 99.9% uptime during exam periods.
● Scalability: Easily expandable for future updates.
4. Appendices
● G lossary:
Aadhaar: Unique Indian identification number.
● Future Enhancements:
Biometric verification, multi-language support.
his version condenses the definitions to their essential points while maintaining the structure of
T
the IEEE 830 format.
ns.1(F)Potential queries for which reports can be generated in theOnline Admit Card
A
Generation System (OACGS):
1. Student Information Reports
L
● ist of students registered for a specific exam.
● Report of students by course or department.
2. Examination Reports
L
● ist of students per examination center.
● Students by examination date and time slot.
3. Admit Card Reports
N
● umber of admit cards generated per day.
● List of students who have not downloaded their admit cards.
4. Administrative Reports
L
● ist of students flagged for administrative review.
● Examination center details (e.g., number of students assigned per center).
5. Notification Reports
L
● ist of email and SMS notifications sent.
● Students who have not received notification.
hese queries will help university staff and administrators generate useful reports to manage the
T
examination process efficiently.
Ans.1(g)
he specific requirements that enable theOnline Admit Card Generation System
T
(OACGS)to run on bothPCs and Mobile Devices:
1. Responsive Design:
○ The system's user interface must be responsive and adaptable to different
screen sizes (desktop, tablet, and mobile).
2. Cross-browser Compatibility:
○ Ensure compatibility with common web browsers like Chrome, Firefox, Safari,
and Edge across PC and mobile platforms.
3. Mobile-friendly UI Elements:
○ Use mobile-optimized input fields, buttons, and menus to ensure ease of use on
touch screens.
4. Adaptive Image Handling:
○ Student images and graphics must be dynamically resized for mobile and
desktop views without loss of quality.
5. Platform-independent Code:
○ Implement using web technologies (HTML5, CSS3, JavaScript) that ensure
functionality on both PC and mobile without platform-specific code.
6. Efficient Loading and Performance:
○ Ensure fast loading times and smooth performance on both high-powered PCs
and lower-spec mobile devices.
7. Touch and Mouse Input Support:
○ The system must support both mouse-based inputs (for PCs) and touch-based
inputs (for mobile devices).
8. Mobile Notifications:
○ Enable mobile-specific features like push notifications or SMS alerts for real-time
updates.
These requirements ensure the OACGS delivers a seamless experience on both platforms.
