[Type here] Faculty of Engineering & Technology

Subject : So ware Engineering

Subject code : 303105254

Prac cal-01
AIM: Project Defini on and Objec ve of the Specified Module
and Perform Requirement Engineering
Project Title:
School Management System (SMS) Project
Overview:
A School Management System is a web-based or desktop applica on
designed to manage all administra ve, academic, and opera onal
ac vi es within a school. The system facilitates the smooth management
of student data, faculty details, course structures, a endance,
examina on management, grade books, and communica on between
parents, students, and teachers.
Objec ve of the Specified Module (e.g., "Student Enrollment and
Management Module"):
For this example, let's assume the specified module is Student Enrollment
and Management. The objec ve of this module is to streamline the
process of registering students in the system, maintain a database of
enrolled students, and manage their academic and personal informa on.
Key objec ves include:
• Simplifying the process of student admission and enrollment into
courses.
• Storing and upda ng student records efficiently.
• Allowing administrators to view student details and track academic
progress.
• Enabling students to register for courses online or through
administra ve assistance.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

• Genera ng and managing reports related to student informa on,

fees, and grades.

Requirement Engineering for School Management System

Requirement engineering is a cri cal phase in the system
development lifecycle. It involves gathering and defining the user
needs and system specifica ons to ensure the project meets
stakeholder expecta ons. Below is a comprehensive approach to
requirement engineering for the School Management System.
1. Requirements Elicita on

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
This step involves gathering requirements from all stakeholders
involved in the project, such as school administrators, teachers,
students, parents, and IT staff.

Key Stakeholders:
• Administrator: School's management staff who oversees the
opera ons.
• Teachers: Faculty members who handle student records and
grades.
• Students: Users of the system who interact with their
academic records.
• Parents: Users who monitor their child’s academic progress.
• IT Staff: Responsible for system maintenance, security, and
updates.
Elicita on Techniques:
• Interviews: Conduc ng interviews with stakeholders to
understand their needs.
• Surveys/Ques onnaires: Sending out ques onnaires to
collect feedback from a larger audience.
• Workshops: Collabora ve discussions among stakeholders to
define objec ves.
• Document Analysis: Reviewing exis ng school records,
paper-based systems, or legacy so ware.

2. Requirements Analysis

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
Once the informa on is gathered, the next step is to analyze and
categorize the requirements.
• Func onal Requirements: What the system must do.

• Non-Func onal Requirements: Constraints and quali es the

system must have.
Func onal Requirements:
• Student Enrollment:
o Admin can add new students. o Students can apply for
admission online (if applicable).
o Admin can assign students to specific courses.
• Student Record Management:
o Store and update student personal informa on (name,
address, date of birth, etc.). o Manage student academic
history (grades, a endance, etc.).
o Generate academic transcripts.
• Course Management:
o Admin can create, modify, or delete courses.
o Teachers can assign students to different sec ons of the
course.
o Students can enroll in available courses.
• A endance Management:

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
o Admin and teachers can track and mark student
a endance.
o Students and parents can view a endance reports.
Non-Func onal Requirements:
• Scalability: The system should be able to handle the growth
of students and courses.

• Security: Sensi ve data such as student informa on and

grades must be encrypted.
• User Interface (UI): The system must have an easy-to- use
and responsive design.
• Performance: The system should load quickly even with a
large number of students and records.
• Availability: The system should be available 24/7 for student
registra on and data access.

3. Requirements Specifica on
Document the func onal and non-func onal requirements in
detail. The requirements specifica on serves as a blueprint for the
system’s design and development.
Example of Func onal Requirements Specifica on for the
Student Enrollment Module:
• Requirement 1: The system must allow administrators to
create a new student profile that includes personal details
such as name, date of birth, address, and guardian
informa on.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
• Requirement 2: The system must validate student data (e.g.,
age limits, correct forma ng of contact numbers).
• Requirement 3: Students must be able to register for
available courses, with course prerequisites checked.
• Requirement 4: The system must allow students to pay
tui on fees, either online or in person, and record payment
details.

Requirement 5: The system must generate an automa c

confirma on of enrollment for students and send it to both
student and guardian via email.

4. Requirements Valida on
Ensure that the requirements meet the needs of all stakeholders
and confirm that they are complete, feasible, and clear.
Methods of Valida on:
• Review Sessions: Involve all key stakeholders in reviewing
the documented requirements.
• Prototyping: Build a prototype of the system and validate
with the users.
• Tes ng: Test the func onality of the system to ensure all
requirements are met.

5. Requirements Management
Once requirements are finalized, the project team should
con nuously manage and update them to reflect any changes
throughout the development lifecycle.
ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
Key Tasks:
• Version Control: Keep track of changes made to the
requirements.
• Change Management: Handle any modifica ons requested
by stakeholders during the development.
• Traceability: Ensure that each requirement is linked to a
specific part of the system design and tes ng phase.

Conclusion
A School Management System is a comprehensive pla orm
aimed at automa ng and organizing various processes in schools.
The Student Enrollment and Management Module aims to
simplify the admission process, keep track of student details, and
facilitate be er interac on between the school administra on,
teachers, students, and parents.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

PRACTICAL-2

Aim: iden fy suitable design and implementa on model from

the different so ware engineering
Introduc on: When selec ng a suitable design and
implementa on model for a School Management System
(SMS), it's crucial to consider the nature of the system, the
complexity of the requirements, and the project's lifecycle.
Below are different So ware Engineering Models and how
they may apply to the development of a School Management
System, along with a recommenda on of the most suitable
model.
*Selec on of a suitable design and implementa on model
* Incremental Model
The Incremental Model involves developing the system in
small, manageable parts (increments). Each increment is
developed, tested, and deployed, and the system is gradually
enhanced in func onality.
Pros:
Allows for par al deployment early in the development
process.
Easier to manage, as the scope is broken down into smaller
modules.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

Flexibility to add new features or adjust the scope a er

feedback from earlier increments.
Reduced risks as the system evolves incrementally.
Cons:
The overall system might lack integra on if not properly
managed.
Can lead to difficul es in maintaining consistency across
increments.
Applicability to SMS:
The Incremental Model is ideal for a School Management
System because it allows for flexibility in managing and
delivering different parts of the system, such as student
enrollment, grading, and a endance management in stages.
You can start by implemen ng the most cri cal features first
(e.g., student registra on) and then incrementally add
features like report genera on, a endance tracking, and
communica on modules.

*Agile Model
The Agile Model emphasizes flexibility, collabora on, and
customer feedback. It follows an itera ve approach, where
the development process is broken down into small,
meboxed itera ons or sprints, delivering incremental
updates to the system. The Agile model is focused on
ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

mee ng the enduser's needs and accommoda ng changes

even a er the project has started.
Pros:
• Highly flexible and adaptable to changing requirements.
• Focuses on user collabora on and customer feedback.
• Delivers working so ware in short itera ons, which
improves user sa sfac on and provides early returns.
• Promotes team collabora on and effec ve
communica on.
Cons:
• Requires con nuous communica on and involvement
from stakeholders.
• Can be challenging to manage if there is a lack of clear
requirements from the start.
• Needs experienced developers and project managers to
handle the itera ve cycles effec vely.
Applicability to SMS:
The Agile Model is an excellent choice for the School
Management System because it allows for rapid prototyping,
early delivery of essen al features, and feedback-driven
development. As school management systems can have
evolving needs, the flexibility of Agile enables the

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

incorpora on of new requirements over me, such as

changes in curriculum, user interfaces, or repor ng needs.
For instance:
• Sprint 1: Basic func onali es such as student
registra on and login.
• Sprint 2: A endance management and fee payment
systems.
• Sprint 3: Grades and reports.
• Sprint 4: Parent-teacher communica on and
no fica on systems.
This itera ve approach allows con nuous tes ng, feedback,
and improvements.
*Design process:
The design process in so ware engineering involves crea ng
a blueprint for the system that will meet the func onal and
non-func onal requirements defined during the
requirements engineering phase. The design process
includes both high-level design (architectural design) and
detailed design to ensure that the system is both feasible and
meets the needs of the stakeholders.
*Implementa on plan:
1. Setup Development Environment

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

Objec ve: Set up the necessary tools, technologies, and

infrastructure for development.

Steps:
Choose Development Tools & Technologies:

. Frontend: React.js or Angular for UI design and interac on.

. Backend: Node.js, Java Spring Boot, or Django for API
development.
. Database: MySQL, PostgreSQL, or MongoDB.
. Version Control: Git (with GitHub or GitLab for
collabora on).
.CI/CD: Jenkins or GitLab CI for con nuous integra on and
deployment.
. Code Editor/IDE: VS Code, IntelliJ IDEA, or Eclipse.
*Comparison of so ware engineering models:

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

Conclusion: Suitable Design and Implementa on Model for a School

Management System
When selec ng a suitable design and implementa on model for a
School Management System (SMS), it is essen al to consider the
specific needs of the system, such as user roles (students, teachers,
administrators, and parents), scalability, security, and performance.
Among the various so ware engineering models, Agile Model with
an Itera ve Design Approach stands out as an ideal choice for the
development of an SMS.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

PRACTICAL-03
AIM: Preparing a so ware Requirements specifica ons (SRS) for the
selected module.
so ware Requirements specifica ons (SRS) for the school
management system
Introduc on:
Crea ng a So ware Requirements Specifica on (SRS) for a School
Management System (SMS) involves defining the func onal and non
func onal requirements, system features, and constraints that the
system must adhere to. The SRS document provides a detailed
descrip on of the system to be developed, ensuring that
stakeholders (developers, users, clients, etc.) have a clear
understanding of the system's requirements.
1.1 Purpose:
The purpose of this document is to define the requirements of
the School Management System (SMS). This system aims to
automate and streamline the management of a school,
including administra on, student management, staff
management, metable scheduling, grading, a endance, and
communica on
1.2 Scope:
The School Management System will serve as a comprehensive
solu on for managing students, teachers, classes, schedules,
grades, a endance, and other administra ve func ons. It will
help streamline communica on between students, teachers,
and parents.
1.3 Defini ons, Acronyms, and Abbrevia ons
 SMS: School Management System
 SRS: So ware Requirements Specifica on

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
Admin: System administrator

 Student: A user who is enrolled in the school
 Teacher: A user who teaches subjects in the school
1.4 Intended Audience
 School administrators
 Teachers and staff
 Students
 Parents
 Developers
1.5 Overview
This document will cover func onal and non-func onal
requirements, system models, external interface requirements,
and other key details needed for the development of the SMS.
2. Overall Descrip on:
This sec on gives a high-level view of the system, including its
objec ves and context.
2.1 Product Perspec ve:
The School Management System is a web-based applica on that will
integrate with exis ng school infrastructure. It is designed to be user
friendly, scalable, and secure.
2.2 Product Features
Student Management: Enrolment, profile management, and report
cards.
Teacher Management: Scheduling, grading, a endance tracking,
and profile management.
Class Scheduling: Timetable management, subject alloca on. 
A endance Management: Daily a endance tracking for students and
teachers.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
 Grade Management: Record and calculate student grades, GPA, etc.
 Communica on Tools: Messaging system for teachers, students, and
parents.
 Fee Management: Fee structure, payments, and outstanding dues.
Repor ng and Analy cs: Generate performance reports and
sta s cal insights.
2.3 User Classes and Characteris cs
Admin: Manages users (students, teachers, staff), oversees all
system func onali es.
 Teachers: Manage student grades, a endance, and schedules.
 Students: View their grades, schedule, and a endance.
Parents: View child’s performance, a endance, and communicate
with teachers.
2.4 Opera ng Environment
 Web-based applica on
 Supported Browsers: Chrome, Firefox, Safari, Edge
 Supported Devices: Desktop, tablet, and mobile devices
2.5 Design and Implementa on Constraints
The system must be scalable to accommodate growth in student
numbers and addi onal features.
It should adhere to standard security prac ces (e.g., SSL encryp on
for sensi ve data).
3. Func onal Requirements:
This sec on outlines the core func onali es of the system.
3.1 User Authen ca on and Access Control

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
 Login: Users must log in using their creden als
(username/password).
Roles: Different roles such as Admin, Teacher, Student, Parent will
have different permissions.
 Password Recovery: Users can reset passwords via email.
3.2 Student Management
Add Student: Admin can add new students, including personal and
academic informa on.
Edit Student Profile: Admin or authorized personnel can edit
student details.
View Student Informa on: Teachers and parents can view student
details (subject to permissions).
3.3 Teacher Management
 Add Teacher: Admin can add new teachers.
 Assign Subjects: Admin can assign subjects and classes to teachers.
View Teacher Informa on: Admin and students can view teacher
details.
 Grade Students: Teachers can input and modify student grades.
3.4 Class and Timetable Management
 Create Class Schedule: Admin or teachers can create and modify
class metables.
 Class Assignment: Admin assigns teachers to classes.
Timetable Display: Students and teachers can view the class
schedule.
3.5 A endance Management

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
 Mark A endance: Teachers can mark daily a endance for each
class.
View A endance: Students and parents can view a endance
records.
3.6 Grade and Performance Management
 Enter Grades: Teachers can input grades for each subject.
Grade Reports: Students and parents can view detailed grade
reports.
GPA Calcula on: The system will calculate and display GPA based on
grades.
3.7 Fee Management
Add Fee Structure: Admin can add different fee categories (tui on,
exams, etc.).
 Pay Fees: Parents can pay school fees online.
 View Fee History: Parents and admin can view fee payment history.
3.8 Communica on Tools
Messaging System: Enables communica on between teachers,
students, and parents.
No fica ons: Alerts for a endance, grades, and other important
updates.
3.9 Repor ng and Analy cs
Performance Reports: Generate individual student performance
reports.
 A endance Reports: View and analyze a endance trends.
Admin Dashboard: A summary of school sta s cs (e.g., total
students, teachers, performance).

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
4. Non-Func onal Requirements These requirements focus on the
performance, security, and usability of the system.
4.1 Performance
 The system should handle at least 500 concurrent users without
significant performance degrada on.
Response me for any ac on should not exceed 3 seconds under
normal load.
4.2 Security
User data, including passwords, should be encrypted using strong
encryp on algorithms (e.g., AES-256).
 Admin should have access to audit logs for all user ac ons.
4.3 Usability
 The system should have an intui ve user interface with minimal
learning curve.
 Mobile-responsive design for access from various devices.
4.4 Scalability
The system should be designed to scale up as the school grows in
terms of students, teachers, and data.
4.5 Availability
 The system should have 99% up me availability.
 Backup and recovery processes should be in place.
5. External Interface Requirements
This sec on defines how the system will interact with other
systems or devices.
5.1 User Interfaces
 Web interface accessible via browsers.
 Mobile interface op mized for touch.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
5.2 Hardware Interfaces
 The system does not require specific hardware but should be
accessible via computers and mobile devices.
5.3 So ware Interfaces
 Database: The system will interact with a rela onal database
like MySQL or PostgreSQL for storing data.
 Payment Gateway: Integra on with third-party payment
systems (e.g., PayPal, Stripe) for fee management.
5.4 Communica on Interfaces
 The system will use email for no fica ons and password
recovery.
 Internal messaging will be used for communica on among
users.
6. Other Requirements
This sec on can contain any addi onal system constraints or
considera ons, such as legal requirements, licensing
informa on, or specific school policies.
* Conclusion The School Management System (SMS) is
designed to streamline and automate various school
administra ve tasks, enhancing the overall efficiency and
experience for students, teachers, parents, and administrators.
This So ware Requirements Specifica on (SRS) document
outlines the system's func onal and non-func onal
requirements, ensuring that all stakeholders have a clear
understanding of the system’s capabili es, constraints, and
expecta ons.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

Prac cal-04
Aim: Develop a So ware project management planning (SPMP) for
the specific module.
A So ware Project Management Plan (SPMP) for a specific module in
a School Management System (SMS) outlines the processes, roles,
goals, and melines necessary to ensure the success of the project.
Below is a detailed plan for a Student Enrollment Module as part of
the School Management System.
1. Introduc on : Project Title: school Management System
The Student Enrollment Module is a part of the larger School
Management System designed to manage student registra on,
tracking, and admission processes for a school. This module will
allow the administra on to enroll students into courses, record
their personal informa on, and handle the applica on process
smoothly.
Objec ve:
To develop a fully func onal Student Enrollment Module that
allows for the following:
 Registra on of students
 Management of student data (personal details, grades, course
preferences)
 Valida on and submission of enrollment forms
 Integra on with other modules like Course Management and
Timetable Management.
2. Scope:
This plan defines the Student Enrollment Module and details
the goals, melines, resources, roles, and processes needed to
develop, test, and implement the module.
The scope includes:

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
 User Interface Design for Student Registra on and Enrollment
 Database design for storing student informa on
 Integra on with authen ca on systems
 Course and session selec on for students
 Reports for student enrollment status
 Role-based access control for admins and students Exclusions:
 Data migra on from old systems
 Third-party integra ons (except payment gateway)
 Advanced analy cs features 3. Project Organiza on Project
Team
 Project Manager (PM):
Oversees the en re project and ensures it adheres to melines
and budget.
 So ware Developers:
Responsible for coding, development, and unit tes ng.
 UI/UX Designer:
Designs the user interface and ensures a user friendly
experience.
 Database Administrator (DBA):
Manages the database design, op miza on, and queries.
 Quality Assurance (QA):
Handles tes ng (manual and automated) and bug tracking.
 System Analyst: Defines requirements and interacts with
stakeholders.
External Stakeholders
 School Administrators: Provide func onal requirements and
tes ng feedback.
 Students: End-users of the system who will interact with the
enrollment forms.
 Teachers: They provide input on the course catalog and course
availability.
4. Project Timeline The meline is broken down into phases.
Here's a rough es mate of the phases:
ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
1. Requirements Gathering and Analysis:
Dura on: 2 weeks
Ac vi es:
o Interview stakeholders (administrators, teachers, etc.)
o Finalize feature list
o Document func onal and non-func onal requirements
2. Design Phase:
Dura on: 3 weeks.
Ac vi es:
o UI/UX Design
o Database schema design
o Develop system architecture
3. Development Phase:
Dura on: 6 weeks
Ac vi es:
o Frontend development for student enrollment forms
o Backend development for handling data submission,
processing, and storing
o Integra on with other system modules
4. Tes ng Phase:
Dura on: 3 weeks
Ac vi es:
o Perform unit tes ng, system tes ng, and integra on tes ng
o Bug fixing and refinements
5. Deployment & Training:
Dura on: 2 weeks
Ac vi es:
o Deploy the system on the produc on server
o Train school administrators and staff
5.Cost Es mate
Budget Breakdown:

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
Personnel Costs:
o Project Manager: $3000
o Developers (2): $5000 each
o UI/UX Designer: $3000
o QA Engineer: $4000
o Database Administrator: $3500
o System Analyst: $3500
 So ware/Tool Costs:
o Development Tools (IDEs, Database Servers): $1500
o Licensing for third-party libraries: $1000
 Miscellaneous Costs:
o Tes ng devices: $500
o Training materials: $500
Total Es mated Cost: $35,500
6. Risk Management
The following risks have been iden fied, along with their
mi ga on strategies:
1.Requirement Change:
Risk: Stakeholders may change requirements during the
development phase.
Mi ga on: Set clear project scope and sign-offs at each
phase. Maintain change control.
2.Integra on Issues: Risk: Integra on with other system modules
could face delays or issues.
Mi ga on: Early integra on tes ng with con nuous
communica on between teams.
3. Delays in Development:
Risk: Developers may encounter technical difficul es or
resource constraints.
Mi ga on: Use agile methodologies to manage itera ons and
adjust deadlines if needed.
4. Data Security Concerns:
ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
Risk: Student data is sensi ve and vulnerable to breaches.
Mi ga on: Implement secure authen ca on mechanisms and
encryp on.
7. Quality Assurance (QA) and Tes ng Tes ng will be conducted in
several phases:
1. Unit Tes ng:
Conducted by developers on individual modules to verify
func onality.
2. Integra on Tes ng:
Ensure that the Student Enrollment Module works well with other
modules (e.g., Course Management, Timetable).
3. User Acceptance Tes ng (UAT):
Perform by school administrators and a group of students to ensure
that the system meets real-world requirements.
4.Performance Tes ng:
Verify system performance under expected load (e.g., mul ple
concurrent users).
5. Security Tes ng: Validate encryp on, authen ca on, and
authoriza on mechanisms.
8. Project Milestones
 Milestone 1: Requirements Document Sign-off (End of Week 2)
 Milestone 2: Design Approval (End of Week 5)
 Milestone 3: Beta Release (End of Week 10)
 Milestone 4: Final System Deployment (End of Week 12)
9. Communica on Plan

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
Weekly Status Updates: Held every Monday via email to report
progress, issues, and upcoming tasks.
Team Mee ngs: Bi-weekly scrum mee ngs to discuss technical
challenges.
Stakeholder Mee ngs: Monthly mee ngs to gather feedback and
adjust project direc on as needed.
10. Conclusion
The Student Enrollment Module aims to streamline the student
registra on process, ensuring that all relevant data is captured and
managed effec vely while integra ng seamlessly with other school
management func ons. Following this SPMP will help keep the
project on track, within scope, and on budget. This document can be
extended with more details as the project progresses, but it serves as
the founda onal plan for the Student Enrollment Module of the
School Management System.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

PRACTICAL-5
Aim: Do cost and effort es ma on using different so ware cost
es ma on models.
Introduc on:
Accurate cost es ma on is crucial for successful so ware projects. It
helps in:
• Budge ng and resource alloca on: Determining the financial
resources required for the project.
• Project planning and scheduling: Crea ng realis c melines and
milestones.
• Risk management: Iden fying poten al cost overruns and
mi ga on strategies.
• Contract nego a on: Establishing fair and reasonable project costs.
Cost Es ma on Models Several models can be used for so ware cost
es ma on:
1. Basic Models:
1. Lines of Code (LOC) based: Es mates effort based on the number
of lines of code (LOC) in the so ware.
▪ Simple: Effort = a * LOC
▪ Limita ons: Difficult to accurately predict LOC in advance, especially
for complex projects.
2. Func on Point Analysis (FPA):
o Measures so ware func onality based on user-oriented features.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
o More accurate than LOC-based models as it considers func onality
rather than lines of code.

o Steps:
▪ Iden fy and count func on points based on user inputs, outputs,
inquiries, files, and interfaces.
▪ Calculate the total number of func on points.
▪ Use historical data to es mate effort based on func on points.
3. COCOMO (Construc ve Cost Model):
o A widely used parametric model that considers various factors,
including project size, experience of the development team,
pla orm, and project constraints.
o Three modes:
▪ Basic COCOMO: For early-stage es ma on.
▪ Intermediate COCOMO: Considers project a ributes like pla orm,
personnel, and project constraints.
▪ Detailed COCOMO: Includes 15 cost drivers that influence effort and
schedule.
4.Expert Judgment:
o Involves es ma ng costs based on the experience and exper se of
project managers, developers, and domain experts.
o Delphi Method: A structured approach to gathering expert
opinions.
Tutorial: Es ma ng Effort for a Hypothe cal Project
Scenario: school management system

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
To es mate the cost and effort involved in developing a School
Management System (SMS), we can apply different so ware cost
es ma on models. Here’s how the es ma on would work for this
kind of project using popular models such as COCOMO, Func on
Point Analysis (FPA), Putnam Model (SLIM), and Es ma on by
Analogy.
For a School Management System, the Func on Point Analysis model
is likely the most suitable due to the focus on func onali es and ease
of use when requirements are well-defined.
2. Func on Point Analysis (FPA)
In Func on Point Analysis, we es mate the cost based on
func onality delivered by the system, not the lines of code. This is
based on coun ng func on points for different components (inputs,
outputs, data files, etc.).
Step 1: Iden fy Func on Points
A typical SMS might include components like:
External Inputs (EI): Student registra on, a endance entry.
External Outputs (EO): A endance reports, grade reports.
Internal Logical Files (ILF): Student records, grade records.
External Interface Files (EIF): Integra on with external systems like
payment gateways.
Assume the following counts for simplicity (these would need to be
adjusted based on the actual system complexity):
EI = 10
EO = 15
ILF = 7
EIF = 3
ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
Step 2: Assign Complexity Weights
Each func on point category is assigned a complexity weight (low,
average, high). Assume average complexity for all categories.

EI (Average): 4
EO (Average): 5
ILF (Average): 7
EIF (Average): 5
Step 3: Calculate Func on Points
The total func on points (FP) are calculated as: FP
FP=(EI×4)+(EO×5)+(ILF×7)+(EIF×5)
FP=(10×4)+(15×5)+(7×7)+(3×5)
Func on Points FP=40+75+49+15=179 Func on Points
Step 4: Convert Func on Points to Effort
Using industry standards, we can es mate effort in person-hours per
func on point. A typical value is 20 hours per FP.
Effort person-hours
Effort=179×20=3,580 person-hours To convert person-hours to
person-months, divide by the number of hours in a month (160
hours/month):
Effort person-months
Effort= 3580/160 =22.38 person-months
Step 5: Calculate Cost
Assuming a cost per person-month of $5,000, the total cost is:
Cost=22.38×5,000=111,900 USD

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
So, the es mated effort is about 22.38 person-months, and the
es mated cost is approximately $111,900.
Conclusion:
Func on Point Analysis offers a more detailed approach based on the
system's func onality, producing a moderate es mate.
Each model has its advantages and is best suited for different types of
projects, but a combina on of these models can o en give a more
accurate es mate.
So ware cost es ma on is an itera ve process that requires
con nuous refinement throughout the project lifecycle.
By using appropriate models and considering relevant factors, you
can improve the accuracy of your es mates and make informed
decisions about project budgets and schedules.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

PRACTICAL-6
Aim: prepare system analysis and system design of iden fied
requirement specifica on using structure design as DFD with data
dic onary and structure chart for the specific module
Project: school management system
System Analysis and Design for a School Management System (SMS)
Let's go through the system analysis and design of the School
Management System (SMS) using structured design with Data Flow
Diagrams (DFD), a Data Dic onary, and a Structure Chart.
Step 1: Understanding the Requirements
The School Management System (SMS) typically manages a variety of
processes and modules such as student ENROLLMENT, grading,
a endance, scheduling, and repor ng.
Iden fied Requirements for SMS:
User Authen ca on – Admin and teachers should be able to log in to
the system.
Student Enrollment – Admin should enroll students in courses.
A endance Management – Teachers should manage student
a endance.
Grading – Teachers should assign grades for students.
Reports – Admin should generate reports for students, courses,
a endance, and grades.
Scheduling – Admin should create and manage class schedules.
Step 2: System Analysis Using DFD (Data Flow Diagram)

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254
A Data Flow Diagram (DFD) helps in understanding how data moves
through the system. We’ll create DFDs at mul ple levels for the
School Management System.
Level 0: Context Diagram (High-Level View)
In this view, we will show the School Management System as a single
process that interacts with external en es such as Admin, Teachers,
and Students.

Processes: The School Management System (SMS) manages

interac ons like enrolling students, tracking a endance, assigning
grades, genera ng reports, etc.
Level 1 DFD: Breaking Down the SMS System
This level involves decomposing the main process into sub-processes.
These processes may include:
User Authen ca on
Student Enrollment
A endance Management
Grading
Repor ng,scheduling

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

User Authen ca on: Admin and Teachers log in.

ENROLLMENT Management: Admin ENROLLS students in courses.
A endance Management: Teachers track student a endance.
Grading: Teachers assign grades for students.
Reports Genera on: Admin generates reports for students, courses,
grades, etc.
Scheduling: Admin schedules classes for teachers and students.
The designed diagram portrays four different scenarios: student
informa on management, enrollment transac on monitoring,
instructor’s informa on management, and checking student year and
status.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

Level 2 DFD :school management system

School Management System is also the highest abstrac on of the
data flow diagram. This level also broadens the idea from the DFD
level 1. It includes the sub-processes from level 1 as well as the data
that flows.

However, not all of the processes in the project must have sub-
processes. Only provide this diagram if needed. As long as your
previous diagrams were clear and precise, this level is not required.
You can add more to this and it is up to you how will you create your
data flow diagram. Also, consider the data flow included and be
precise with your informa on.

ERP NO : 2303031460087
[Type here] Faculty of Engineering & Technology
Subject : So ware Engineering
Subject code : 303105254

Data Dic onary:

A Data Dic onary defines the data elements used across different
processes in the system, along with their a ributes.

Conclusion:
The System Analysis and Design for the School Management System
(SMS) using structured design can be broken down into the following
components:
DFD: The system is broken down into high-level processes, such as
user authen ca on, student ENROLLMENT, a endance management,
grading, scheduling, and report genera on.
Data Dic onary: Defines the data elements and a ributes required
for the system.

ERP NO : 2303031460087
 Practical-7
AIM: Desing the module using object oriented approach including use
case diagram with scenarios, class diagram and state diagram, sequence
diagram activity, diagram.
A School Management System (SMS) helps manage various aspects of a
school's operations, including student records, faculty management,
courses, attendance, and exams. Below is an object-oriented design
(OOD) approach for the SMS, along with UML diagrams.

1. Use Case Diagram

The Use Case Diagram represents the interactions between users
(actors) and the system.
Actors:
 Admin: Manages users, schedules, and resources.
 Teacher: Manages courses, marks attendance, and grades
students.
 Student: Views grades, schedules, and submits assignments.
 Parent: Monitors student progress.
Use Cases:
1. Manage Student Records (Add, Edit, Delete)
2. Manage Teachers & Staff
3. Assign Courses to Teachers

ERP NO :2303031460087
 4. Mark Attendance
5. Manage Exams & Results
6. Schedule Timetable
7. Generate Reports

ERP NO :2303031460087
2. Class Diagram
A Class Diagram defines the main objects and their relationships.
Main Classes:
1. User (Abstract Class)
o Attributes: user ID, name, email, password
o Methods: login (), logout ()
2. Admin (Inherits User)
o Methods: add Student (), remove Student (), assign Teacher
(), generate Report ()
3. Teacher (Inherits User)
o Attributes: teacher ID, specialization
o Methods: assign Grades (), mark Attendance ()
4. Student (Inherits User)
o Attributes: student ID, grade
o Methods: view Attendance (), view Grades ()
5. Course
o Attributes: course ID, course Name, teacher ID
o Methods: assign Teacher ()
6. Attendance
o Attributes: attendance ID, student ID, date, status

ERP NO :2303031460087
 o Methods: mark Attendance (), get Attendance Report ()
7. Exam
o Attributes: exam ID, course ID, date
o Methods: schedule Exam (), assign Grade ()

3. State Diagram
The State Diagram represents the different states of a student.
States:

ERP NO :2303031460087
 1. New Registration
2. Enrolled
3. Active in Course
4. Exams Pending
5. Graduated
6. Withdrawn

ERP NO :2303031460087
4. Sequence Diagram
Scenario: Teacher Marks Attendance
1. Teacher logs in.
2. Selects a course.
3. Chooses a date.
4. Marks students present/absent.
5. Attendance data is stored.

ERP NO :2303031460087
5. Activity Diagram
Scenario: admin Viewing Grades
1. Student logs in.

ERP NO :2303031460087
 2. Navigates to "Grades".
3. Selects a course.
4. Views grade details.
5. Logs out.

ERP NO :2303031460087
ERP NO :2303031460087
 Faculty of Engineering & Technology Subject-Name:
software Engineering laboratory.

Subject-Code: 203105304
B.tech CSE year: 2nd semester:4th

Practical -8
AIM: Defining Coding Standards and walk through.
Coding Standards: When building a School Management System (SMS), it's crucial to establish
coding standards that ensure maintainability, scalability, and collaboration across the development
team. This system typically includes modules for student management, staff management, courses,
exams, grades, and more. Given the complexity, defining coding standards tailored to the School
Management System is necessary to streamline development and ensure consistent practices
across different components of the system.

Coding Standards Walkthrough for a School Management System

1. General Practices

• Modular Design: Break the system into smaller, logically organized components or
modules. For instance, create separate modules for Student, Teacher, Class, Exam, etc.

• Use of MVC Architecture: Adopt Model-View-Controller (MVC) design pattern to

separate data (model), logic (controller), and presentation (view).

• Version Control: Use Git and follow a consistent branching strategy (e.g., main for
production, develop for staging, feature branches for new features).

• Consistency: Ensure consistent use of naming conventions, indentation, and structure

throughout the entire codebase.

2. Naming Conventions

• Classes: Follow Pascal Case for class names, which represent entities like Student, Teacher,
Course.

o Example: Student Record, Course Schedule, Teacher Attendance

• Variables and Functions: Use camelCase for variables and functions. Use descriptive
names for functions that clearly define actions (e.g., add Student (), get Exam Results ()).

o Example: add Student(), update Student Info (), calculate Grade()

• Tables and Columns: For database table names, use snake case (e.g., students, courses,
exam results). For column names, ensure they reflect the type of data they hold.

Enrolment no:2303031460087
 Faculty of Engineering & Technology Subject-Name:
software Engineering laboratory.

Subject-Code: 203105304
B.tech CSE year: 2nd semester:4th

o Example: student, first name, total marks

• Constants: Constants should be in UPPERCASE with underscores separating words.

o Example: MAX_STUDENTS_PER_CLASS, MIN_PASSING_GRADE

3. Indentation and Code Formatting

• Indentation: Use 4 spaces for each indentation level.

• Line Length: Ensure no line exceeds 80 characters for better readability.

• Braces: Use K&R style braces for languages like JavaScript or Allman style for languages
like Python.

• Empty Lines: Separate logical blocks of code with a single empty line. Functions should
have a single line separating them.

4. Commenting and Documentation

• Inline Comments: Use comments to explain complex or non-obvious code logic.

Function and Method Documentation: Each function should have a docstring to explain what
it does, the parameters it accepts, and the return values.

Documentation for APIs: If your SMS exposes APIs (e.g., for mobile apps or external systems),
each endpoint should be well-documented using a standard like OpenAPI/Swagger

5. Database Design and Query Best Practices

• Database Tables: Normalize the database to avoid redundancy. Use
appropriate data types for each column.
• Primary Keys and Foreign Keys: Use primary keys (student_id,
teacher_id) to uniquely identify records and foreign keys to maintain
relationships.
• Query Optimization: Always optimize database queries for performance,
particularly for complex reports like student performance over a
semester

Enrolment no:2303031460087
 Faculty of Engineering & Technology Subject-Name:
software Engineering laboratory.

Subject-Code: 203105304
B.tech CSE year: 2nd semester:4th

6. Error Handling and Logging

• Error Handling: Use try-except blocks (in Python) or equivalent in other
languages to handle potential errors gracefully.
Logging: Implement logging at different levels (INFO, WARNING, ERROR) for
debugging and monitoring.
7. Security Practices
• Authentication and Authorization: Use secure authentication methods
like JWT tokens or OAuth2 for managing user sessions.
• Data Validation: Always validate input data to avoid SQL injection and
cross-site scripting (XSS) vulnerabilities.
o Example: Ensure that the student_id passed to a query is an
integer.
• Password Storage: Store passwords using strong encryption algorithms
like bcrypt

• a School Management System (SMS) ensures that the system is

maintainable, scalable, and easy to understand. The key aspects of coding
standards include clear naming conventions, consistent formatting,
detailed documentation, and a structured approach to handling errors and
security. By establishing these standards, teams can work efficiently,
avoid common pitfalls, and produce high-quality code that can easily be
extended or modified as the system evolves.

Enrolment no:2303031460087
 Faculty of Engineering & technology
Subject: software Engineering
Subject code: 303105253
B.tech CSE 2nd year AIML 4th sem

PRACTICAL: 9

AIM: write the test cases for the identified module

Project: school management system

To write test cases for a School Management System (SMS), let's

first identify some typical modules within the system. These
modules can include:
1. Student Management
2. Teacher Management
3. Class Management
4. Attendance Management
5. Grades and Report Cards

Erp:2303031460087
 Faculty of Engineering & technology
Subject: software Engineering
Subject code: 303105253
B.tech CSE 2nd year AIML 4th sem
6. Timetable Management
7. User Authentication (Login and Registration)
8. Fee Management
9. Examination Management
I'll provide a set of sample test cases for each of these modules,
which can be adapted as needed.
1. Student Management Module
Test Case 1: Add New Student
• Test Case ID: SM_001

• Pre-condition: Admin or authorized user is logged in.

• Test Steps:
1. Navigate to the "Student Management" section.
2. Click on the "Add New Student" button.
3. Fill in required student details (name, date of birth,
address, grade, parent contact information).
4. Click "Save."
• Expected Result: A confirmation message appears, and the
new student is added to the database.
• Post-condition: The student is now listed in the system.
Test Case 2: View Student Information
• Test Case ID: SM_002

• Pre-condition: Admin or authorized user is logged in.

• Test Steps:
1. Navigate to the "Student Management" section.
2. Search for an existing student by name or student ID.
3. Click on the student's name.

• Expected Result: The student's complete information

(personal details, enrollment, grades) is displayed.
Erp:2303031460087
 Faculty of Engineering & technology
Subject: software Engineering
Subject code: 303105253
B.tech CSE 2nd year AIML 4th sem
• Post-condition: User has viewed the student's profile.

2. Teacher Management Module

Test Case 1: Add New Teacher
• Test Case ID: TM_001

• Pre-condition: Admin or authorized user is logged in.

• Test Steps:
1. Navigate to the "Teacher Management" section.
2. Click on the "Add New Teacher" button.
3. Enter the teacher's details (name, subject, qualifications,
contact information).
4. Click "Save."
• Expected Result: A confirmation message appears, and the
new teacher is added to the system.
• Post-condition: The teacher is now listed in the system.
Test Case 2: Assign Teacher to Class
• Test Case ID: TM_002

• Pre-condition: Admin or authorized user is logged in.

• Test Steps:
1. Navigate to the "Teacher Management" section.
2. Select a teacher from the list.
3. Choose the class/subject to assign the teacher.
4. Click "Save."
• Expected Result: Teacher is assigned to the class/subject,
and this information is updated.
• Post-condition: Teacher is successfully assigned.

3. Class Management Module

Test Case 1: Create a New Class
Erp:2303031460087
 Faculty of Engineering & technology
Subject: software Engineering
Subject code: 303105253
B.tech CSE 2nd year AIML 4th sem
• Test Case ID: CM_001
• Pre-condition: Admin or authorized user is logged in.
• Test Steps:
1. Navigate to the "Class Management" section.
2. Click on the "Create New Class" button.
3. Enter class details (class name, grade, subjects,
timetable).
4. Click "Save."
• Expected Result: A confirmation message appears, and the
new class is created.
• Post-condition: The new class is added to the system.
Test Case 2: Edit Class Information
• Test Case ID: CM_002

• Pre-condition: Admin or authorized user is logged in.

• Test Steps:
1. Navigate to the "Class Management" section.
2. Select a class to edit.
3. Update class details (e.g., class teacher, subjects,
timetable).
4. Click "Save."
• Expected Result: The class information is updated
successfully.
• Post-condition: The class details are saved with the new
information.

4. Attendance Management Module

Erp:2303031460087
 Faculty of Engineering & technology
Subject: software Engineering
Subject code: 303105253
B.tech CSE 2nd year AIML 4th sem
Test Case 1: Mark Student Attendance
• Test Case ID: AM_001

• Pre-condition: Admin, teacher, or authorized user is logged

in.
• Test Steps:
1. Navigate to the "Attendance Management" section.
2. Select the class and date.
3. Mark students as present/absent.
4. Click "Save."
• Expected Result: The attendance is successfully recorded for
the selected class.
• Post-condition: Attendance data is saved.
Test Case 2: View Attendance Report
• Test Case ID: AM_002

• Pre-condition: Admin or authorized user is logged in.

• Test Steps:
1. Navigate to the "Attendance Management" section.
2. Select a student or class and specify the date range.
3. Click "View Report."
• Expected Result: A detailed attendance report for the
selected student/class is displayed.
• Post-condition: The report is available for review.

5. Grades and Report Cards Module

Test Case 1: Enter Grades for Students
• Test Case ID: GR_001

.
Erp:2303031460087
 Faculty of Engineering & technology
Subject: software Engineering
Subject code: 303105253
B.tech CSE 2nd year AIML 4th sem
• Test Steps:
1. Navigate to the "Grades" section.
2. Select the class and student.
3. Enter grades for various subjects.
4. Click "Save."
• Expected Result: The grades are saved, and the student’s
record is updated.
• Post-condition: Grades are recorded in the system.
Test Case 2: Generate Report Cards
• Test Case ID: GR_002

• Pre-condition: Admin or teacher is logged in.

• Test Steps:
1. Navigate to the "Report Cards" section.
2. Select a student and specify the term/semester.
3. Click "Generate Report."
• Expected Result: A report card is generated with the
student's grades and performance.
• Post-condition: Report card is ready for download or
printing.

6. User Authentication (Login and Registration)

Test Case 1: User Login with Correct Credentials
• Test Case ID: UA_001

• Pre-condition: The user is registered in the system.

Test Steps:
1. Navigate to the login page.
2. Enter the correct username and password.
3. Click "Login."

Erp:2303031460087
 Faculty of Engineering & technology
Subject: software Engineering
Subject code: 303105253
B.tech CSE 2nd year AIML 4th sem
• Expected Result: User is redirected to the
dashboard/homepage.
• Post-condition: User is logged in successfully.
Test Case 2: User Login with Incorrect Credentials
• Test Case ID: UA_002

• Pre-condition: The user is registered in the system.

• Test Steps:
1. Navigate to the login page.
2. Enter an incorrect username or password.
3. Click "Login."
• Expected Result: An error message appears indicating
incorrect credentials.
• Post-condition: User remains on the login page.

7. Fee Management Module

Test Case 1: Add School Fee for Student
• Test Case ID: FM_001

• Pre-condition: Admin or authorized user is logged in.

• Test Steps:
1. Navigate to the "Fee Management" section.
2. Select a student.
3. Enter the fee details (amount, due date, payment status).
4. Click "Save."

• Expected Result: The fee is recorded, and the student’s fee

status is updated.
• Post-condition: Fee is added to the student's account.
Test Case 2: View Fee Status for Student
• Test Case ID: FM_002
Erp:2303031460087
 Faculty of Engineering & technology
Subject: software Engineering
Subject code: 303105253
B.tech CSE 2nd year AIML 4th sem
• Pre-condition: Admin or authorized user is logged in.
• Test Steps:
1. Navigate to the "Fee Management" section.
2. Search for a student.
3. View the student's fee details and payment status.
• Expected Result: The fee information for the student is
displayed correctly.
• Post-condition: The fee status is available for review.

Conclusion:
These test cases cover some of the core modules in a School
Management System. You can expand or modify these test cases
based on the specific requirements and functionalities of the
system. If you need test cases for more modules or further details
on any module, feel free to let me know!

Erp:2303031460087