‭MCS -213‬

‭Software Engineering‬

‭ ues-1‬‭Assume that you are assigned responsibility………………………………………………‬

Q
‭………………………………………………………………needs to be generated.‬

‭ ns. 1 (a)‬‭For developing the Online Admit Card Generation‬‭System (OACGS), an‬‭Agile SDLC‬
A
‭paradigm‬‭would be the most suitable, though we could‬‭also 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?‬

‭●‬ I‭ncremental Delivery‬‭: Agile allows for step-by-step‬‭delivery of key modules like‬
‭registration, validation, and admit card generation.‬
‭●‬ ‭Flexibility & Feedback‬‭: Iterative sprints enable quick‬‭adjustments based on student or‬
‭admin feedback, ideal for a dynamic system like OACGS.‬
‭●‬ ‭Cross-platform Compatibility‬‭: Early testing on both‬‭PC and mobile ensures a‬
‭seamless experience.‬
‭●‬ ‭Risk Management‬‭: Security and functionality are tested‬‭incrementally, reducing overall‬
‭risk.‬

‭Agile Workflow:‬

‭‬ D
● ‭ evelopment happens in‬‭sprints‬‭with continuous‬‭feedback‬‭.‬
‭●‬ ‭Early delivery‬‭of 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 both‬‭PC and mobile from the start.‬
‭●‬ ‭Real-time Feedback‬‭: Continuous feedback loop during‬‭module development.‬
‭●‬ ‭Security-First‬‭: Each module undergoes security testing‬‭before integration.‬

‭Justification:‬

‭‬ S
● ‭ calability‬‭: New features can be added easily through‬‭modular development.‬
‭●‬ ‭Quick Adaptation‬‭: AMD allows rapid changes, ideal‬‭for handling dynamic data like‬
‭exam schedules or new course codes.‬
‭●‬ ‭Cross-platform Compatibility‬‭: Built-in from the start‬‭to avoid later adjustments.‬

‭Conclusion:‬

‭ gile‬‭offers flexibility and iterative delivery, while‬‭the proposed‬‭AMD‬‭paradigm 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 the‬‭Online Admit Card Generation‬
‭ ystem (OACGS)‬‭, we can break it down by key modules‬‭and 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 the‬‭Online 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 ensure‬‭data privacy‬‭.‬
‭●‬ ‭Must work on both‬‭PCs and mobile devices‬‭.‬

‭2.5 Assumptions and Dependencies‬

‭‬ E
● ‭ xisting‬‭student databases‬‭and‬‭exam schedules‬‭are‬‭available.‬
‭●‬ ‭Relies on third-party services for‬‭Aadhaar validation‬‭and‬‭notifications‬‭.‬

‭3. Specific Requirements‬

‭3.1 Functional Requirements‬

‭‬
● ‭ ser Authentication‬‭: Students log in with credentials.‬
U
‭●‬ ‭Examination Form‬‭: Students fill in and submit their‬‭details.‬
‭●‬ ‭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 the‬‭Online 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 the‬‭Online Admit Card Generation System‬

T
‭(OACGS)‬‭to run on both‬‭PCs 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.‬