Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

INDEX

S.no Practical’s Page No Remarks

1. Identify project scope and objective of given problem: a.

College automation system.
b. Banking management System.

2. Develop software requirements specification for (1 a.) and (1 b.) problem.

3. Develop UML Use case model for a problem.

4. Develop Class diagrams

5. Represent project Scheduling of above-mentioned projects

6. Use any model for estimating the effort, schedule, and cost of software
project
7. Develop DFD model (level-0, level-1 DFD and Data dictionary) of the project

8. Develop sequence diagram

9. Develop Structured design for the DFD model developed

10. Develop the waterfall model, prototype model and spiral model of the
product
11. Explain with reason which model is best suited for the product

12. Develop a working protocol of any of two problems

13. Use LOC, FP, and Cyclomatic Complexity Metric of above-mentioned problem

14. Find Maintainability Index and Reusability Index of above-mentioned

problem
15. Using any Case Tool find number of statements, depth, and complexity of
the prototype
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical No 1 - Identify project scope and objective of given problem:

College Automation System
Project Scope:
1. Student Management:
• Registration of students.

•Management of student profiles, including personal information, academic

records, and attendance.

• Generation of student IDs, class schedules, and academic transcripts.

2. Faculty Management:
• Registration and management of faculty profiles.

• Assignment of courses to faculty.

• Tracking faculty schedules and academic performance.

3. Course Management:
• Creation and management of course catalogs.

• Assignment of courses to semesters/academic terms.

• Tracking course enrollment and availability.

4. Attendance and Grading:

• Recording and monitoring student attendance.

• Managing grading systems and recording student grades.

5. Financial Management:
• Management of tuition fees, scholarships, and financial aid.

• Billing and payment processing for students.

6. Library Management:
• Management of library resources including books, journals, and digital materials.

•Check-in/check-out processes.

•Tracking overdue items and fines.

7. Administrative Functions:
•Human resources management.

•Facilities management.

•Reporting and analytics.

Objectives:
1. Efficiency: Automate administrative tasks to streamline operations and reduce manual
effort.
2. Accuracy: Ensure accurate recording and reporting of student and faculty data.
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

3. Transparency: Provide stakeholders (students, faculty, administrators) with access to

relevant information.

4. Compliance: Ensure compliance with regulatory requirements and institutional policies.

Banking Management System

Project Scope:
1. Customer Management:
• Registration and management of customer profiles.

• Account creation, closure, and maintenance.

•KYC (Know Your Customer) compliance.

2. Transaction Management:
• Handling deposits, withdrawals, and transfers.

• Managing loan applications and approvals.

• Processing bill payments and standing instructions.

3. Security and Fraud Detection:

• Implementing security measures for authentication and authorization.

• Monitoring transactions for suspicious activities and fraud prevention.

4. Interest and Investment Management:

• Calculating and managing interest rates for accounts.

• Offering investment products like fixed deposits, mutual funds, etc.

5. Reporting and Analytics:

• Generating reports on account balances, transactions, and financial performance.

• Analyzing customer behavior and trends to improve services.

6. Online and Mobile Banking:

• Providing online and mobile banking services for customer convenience.

• Ensuring security and reliability of digital channels.

Objectives:
1. Efficiency: Streamline banking operations to reduce processing time and costs.

2. Security: Implement robust security measures to protect customer data and prevent

fraud.

3.Customer Satisfaction: Enhance customer experience through convenient and

accessible banking services.

4. Compliance: Ensure compliance with banking regulations and standards.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

5.Profitability: Optimize revenue generation through effective management of

interest rates and investment products

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 2(a) - Develop software requirements specification for College Automation

System.
1. Introduction

1.1 Purpose

The primary objective of this document is to provide a comprehensive outline of the requirements for the

development of the College Automation System. This system aims to modernize and streamline various

administrative processes within the college environment, facilitating efficient management of student,

faculty, course, financial, and library-related activities.

1.2 Scope

The College Automation System will cover a wide range of functionalities including student registration,

enrollment management, course scheduling, attendance tracking, grading, fee management, library resource

management, faculty administration, and reporting. The system will target colleges and educational

institutions seeking to enhance operational efficiency and improve the overall learning experience for

students and faculty.

1.3 Definitions and Abbreviations

SRS: Software Requirements Specification

CMS: College Management System

UI: User Interface

API: Application Programming Interface

HR: Human Resources

1.4 References

This section will contain references to relevant documents, standards, and external resources used in the

development of the College Automation System.

1.5 Overview

The document will provide an overview of the College Automation System, including its objectives, scope, key

features, and target users. It will serve as a guide for stakeholders involved in the development, implementation, and

maintenance of the system.

2. Overall Description

2.1 Product Perspective

The College Automation System will serve as an integrated platform that interfaces with existing systems such as

student databases, HR management systems, financial software, and library management systems. It will provide a
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

centralized hub for managing various aspects of college administration, promoting collaboration and efficiency

across different departments.

2.2 Product Functions

The system will offer a wide range of functions including:

Student management: Registration, enrollment, and academic record management.

Faculty management: Profile creation, course assignment, and performance tracking.

Course management: Catalog creation, scheduling, and enrollment management.

Attendance tracking: Recording student attendance and generating reports.

Grading: Managing grading systems and recording student grades.

Financial management: Fee collection, scholarship management, and financial reporting. Library

management: Inventory management, check-in/check-out, and overdue tracking.

Administrative functions: HR management, facilities management, and reporting.

2.3 User Characteristics

The system will cater to various user roles including administrators, faculty members, students, and staff members.

Users may have different levels of technical proficiency and access privileges within the system. The user interface

will be designed to accommodate the needs of users with diverse backgrounds and preferences.

2.4 External Constraints

External constraints may include budget limitations, time constraints for implementation, compatibility with existing

infrastructure, and compliance with regulatory requirements such as GDPR and FERPA.

2.5 Assumptions and Dependencies

The successful implementation of the College Automation System assumes the availability of reliable internet

connectivity, adequate hardware infrastructure, and cooperation from stakeholders for data migration and

integration. Dependencies may include third-party APIs, software libraries, and external data sources. 3.

Detailed Requirements Specification

3.1 External Interface Specification

3.1.1 User Interface

The user interface should be intuitive, responsive, and accessible across devices. It should support features such as

role-based access control, customizable dashboards, and multilingual support.

3.1.2 Hardware Interface

The system should be compatible with standard hardware configurations including computers, servers, printers,

biometric devices, and RFID scanners for library management.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

3.1.3 Software Interface

Integration with existing systems such as databases, authentication systems, payment gateways, and learning

management systems should be seamless via APIs and web services.

3.1.4 Communication Interface

The system should support various communication channels including email notifications, SMS alerts, in-app
messaging, and push notifications for effective communication with stakeholders.

3.2 Functional Requirements

3.2.1 Student Management Module

This module should allow for the registration, enrollment, and management of student profiles, including personal

information, academic records, and attendance.

3.2.2 Faculty Management Module

This module should facilitate the creation and management of faculty profiles, course assignment, and performance

tracking.

3.2.3 Course Management Module

This module should support the creation of course catalogs, scheduling, enrollment management, and course

evaluation.

3.2.4 Attendance Tracking Module

This module should enable the recording of student attendance, monitoring of attendance patterns, and generation

of attendance reports.

3.2.5 Financial Management Module

This module should handle fee collection, scholarship management, financial reporting, and billing for students 3.2.6

Library Management Module

This module should manage library resources, including inventory management, check-in/check-out, and overdue

tracking.

3.3 Performance Requirements

The system should be able to support a large number of concurrent users and handle peak loads efficiently. Response

times for queries and transactions should be fast, and the system should be able to handle large volumes of data

without degradation in performance.

3.4 Design Constraints

Design constraints may include compatibility with specific programming languages, frameworks, and database

technologies. The system architecture should be scalable, modular, and maintainable to accommodate future

enhancement and changes.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

3.5 Attributes

Attributes such as scalability, reliability, security, and maintainability should be incorporated into the design of the

system. The system should be able to recover gracefully from failures and ensure data integrity and confidentiality.

3.6 Other Requirements

Other requirements may include backup and recovery mechanisms, disaster recovery plans, and compliance with

data protection regulations such as GDPR and FERPA. The system should undergo regular maintenance and updates

to address security vulnerabilities and improve functionality based on user feedback.

Practical 2(b) - Develop software requirements specification for Banking

Management System

1. Introduction 1.1

Purpose

The purpose of this document is to define the requirements for the development of a Banking Management System.

This system aims to provide a comprehensive platform for managing various banking operations, including customer

management, transaction processing, security, compliance, and reporting.

1.2 Scope

The Banking Management System will cover a wide range of functionalities, including customer registration, account

management, transaction processing, loan management, security features, reporting, and compliance with

regulatory requirements.

1.3 Definitions and Abbreviations

SRS: Software Requirements Specification

BMS: Banking Management System

UI: User Interface

API: Application Programming Interface

KYC: Know Your Customer

1.4 References

This section will contain references to relevant banking regulations, industry standards, and external resources used

in the development of the Banking Management System.

1.5 Overview

The document will provide an overview of the Banking Management System, its objectives, scope, key features, and

target users. It will serve as a guide for stakeholders involved in the development, implementation, and maintenance

of the system.
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

2. Overall Description

2.1 Product Perspective

The Banking Management System will function as an integrated platform that interfaces with existing banking

systems such as core banking systems, payment gateways, and regulatory reporting systems. It will provide a

centralized hub for managing various banking operations and ensuring seamless integration with external systems.

2.2 Product Functions

The system will offer a wide range of functions including:

Customer management: Registration, account opening, and KYC compliance.

Transaction processing: Deposits, withdrawals, fund transfers, bill payments, and loan disbursements.
Loan management: Loan application processing, approval, and repayment tracking.

Security features: Authentication, authorization, fraud detection, and encryption.

Reporting: Generating reports on account balances, transactions, financial performance, and regulatory compliance.

2.3 User Characteristics

The system will cater to various user roles including bank employees, customers, administrators, and regulatory

authorities. Users may have different levels of technical proficiency and access privileges within the system. The user

interface will be designed to accommodate the needs of users with diverse backgrounds and preferences.

2.4 External Constraints

External constraints may include compliance with banking regulations such as Basel III, GDPR, and PCI DSS, as well as

compatibility with existing banking infrastructure, budget limitations, and time constraints for implementation.

2.5 Assumptions and Dependencies

The successful implementation of the Banking Management System assumes the availability of reliable internet

connectivity, adequate hardware infrastructure, and cooperation from stakeholders for data migration and

integration. Dependencies may include third-party APIs, software libraries, and regulatory reporting systems. 3.

Detailed Requirements Specification

3.1 External Interface Specification

3.1.1 User Interface

The user interface should be intuitive, responsive, and accessible across devices. It should support features such as

multi-factor authentication, customizable dashboards, and real-time notifications for transactions.

3.1.2 Hardware Interface

The system should be compatible with standard banking hardware including ATMs, card readers, cash dispensers,

and biometric devices for authentication.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

3.1.3 Software Interface

Integration with existing banking systems such as core banking systems, payment gateways, and regulatory reporting

systems should be seamless via APIs and web services.

3.1.4 Communication Interface

The system should support secure communication channels including encrypted connections for online banking,

secure email for communication with customers, and APIs for integration with external systems.

3.2 Functional Requirements

3.2.1 Customer Management Module

This module should allow for the registration, account opening, and management of customer profiles, including KYC

compliance and account verification.

3.2.2 Transaction Processing Module

This module should facilitate various types of transactions including deposits, withdrawals, fund transfers, bill
payments, and loan disbursements.

3.2.3 Loan Management Module

This module should support the processing of loan applications, approval workflows, loan disbursements, and

repayment tracking.

3.2.4 Security Features Module

This module should implement security features such as multi-factor authentication, encryption of sensitive data,

fraud detection, and authorization controls.

3.2.5 Reporting Module

This module should generate reports on account balances, transaction history, financial performance, regulatory

compliance, and audit trails.

3.3 Performance Requirements

The system should be able to handle a large number of concurrent users and transactions with minimal latency.

Response times for transactions should be fast, and the system should be able to handle peak loads efficiently.

3.4 Design Constraints

Design constraints may include compliance with specific banking regulations and standards, compatibility with

legacy systems, and scalability to accommodate future growth and expansion.

3.5 Attributes

Attributes such as scalability, reliability, security, and maintainability should be incorporated into the design of the

system. The system should ensure data integrity, confidentiality, and availability, and provide mechanisms for

disaster recovery and business continuity.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

3.6 Other Requirements

Other requirements may include backup and recovery mechanisms, disaster recovery plans, compliance with data

protection regulations, and regular security audits and penetration testing to identify and mitigate vulnerabilities.
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 3 - Develop UML Use case model for a problem.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 4 - Develop Class diagrams.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 5 - Represent project Scheduling of above-mentioned projects.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 6 - Use any model for estimating the effort, schedule, and cost of
software project.
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 7 - Develop DFD model (level-0, level-1 DFD and Data dictionary)
of the project.
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 8 - Develop sequence diagram.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 9 - Develop Structured design for the DFD model developed.

 Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 10:- Develop the Waterfall model, Prototype model and Spiral model of the
product. Waterfall model

Introduction: - The waterfall model is the basic software development life cycle (SDLC) model. It is very
simple but idealistic. Earlier it was very popular but nowadays it is not used much but it is very important
because all the other software development life cycle models are based on the classical waterfall model. In
this model development process can be considered as sequential flow and phases do not overlap with each
other. The different sequential phases of waterfall model are shown in the below figure.

Advantages of waterfall model:-

Waterfall model is very simple and is easy to understand
Phases in this model are processed one at a time.
Each stage in the model is clearly defined.
This model has very clear and well defined milestones.
Process, actions and results are very well documented.
This model works well for smaller project where requirements are well
understood.

Drawbacks of waterfall model:-

We can use it in real projects but we use other software development lifecycle models which are
based on the classical waterfall model.
Waterfall model is not a good model for complex and object oriented projects.
Poor model for long and ongoing projects no working software is produced until late during the
Cycle High amounts of risk and uncertainty.

Once a application is in the testing stage it is very difficult to go back and change something that was
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

not well thought out in the concept stage

Prototype Model
Introduction:- Prototyping Model is a software development model in which prototype is built, testes and
rework until an acceptable prototype is achieved. It also creates base to base to produce the final system
or software. It works best in scenarios where the project’s requirements are not known in detail. It is an
iterative, trial and error method which takes place between developer and client. Prototype is defined
as the process of developing a working replication of a product and is used for obtaining customer
feedback.

Advantages of prototype:-
Users are actively involved in the development.
Since in this methodology a working model of the system is provided, the users get a better
understand of the system being developed.
Errors can be detectd much earlier.
Quicker user feedback is available leading to better solutions.
Missing functionality can be identified easily.
Confusing or difficuilt functions can be identified requerments validation, quick implementation of
incomplete but functional applcation.

Drawbacks of prototype model:-

Leads to implementing and then repairing way of building systems.
Practially this methodology may increase the complexity of the system as scope of the system may
expend beyond origininal plans.
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Incomplete application may cause application may not be used as the full system was designed

incomplete or inadequate problem analysis

Sprial Model

Introduction:- The sprial model is a risk-driven softwre development process model. It is a of

waterfall model and iterative model.sprial model helps to adopt software development elements of
multiple process models for the software project based on unique risk patterns ensuring efficient
development process. The development proess in sprial model starts with a small set of requirement and
goes through each development phase for those set of rwquriments.the below figure very well explain
sprial model.

Advantages of sprial model:-

Additional functionally or changes can be done at a later stage.
Cost estimate easy as the prototype building is done in small fragments.
Continous or repeated development helps risk management.
Development is fast and features are added in a systematic way in sprial development.
There is always a space for customer feedback.

Drawbacks of sprial mode:-

Risk of not meeting the schedule or budget
Sprial development works best for large projects only also demands risk assessment expertise.
For its smooth operation sprial model protocol needs to be followed strictly.
Documentation is more as it has intermediate phase.
Sprial software is not advisable for smaller project,it might cost them a lot
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 11 - Explain with reason which model is best suited for the product
The Waterfall Model is a traditional sequential design process used in software development,
where progress flows in one direction through several phases such as requirements gathering, design,
implementation, testing, deployment, and maintenance. Let's explore why the Waterfall Model might be
best suited for developing a college management system:

Clear Requirements: College management systems often have well-defined requirements due to
structured nature. The Waterfall Model's initial phase focuses on gathering and documenting these
requirements thoroughly. This ensures that all stakeholders have a clear understanding of what needs to
be built before development begins.
Stable Requirements: In many cases, the requirements for a college management system remain
stable throughout the development process. Once requirements are finalized, changes are often minimal.
The Waterfall Model's linear approach is well-suited for projects with stable requirements because it
discourages frequent changes after the initial planning phase.

Comprehensive Planning: The Waterfall Model encourages comprehensive planning upfront. This is
beneficial for a college management system, which typically requires integration with various existing
systems (e.g., student databases, course schedules, financial records). Detailed planning helps identify
potential integration points and dependencies early in the development process, reducing the likelihood
of delays or rework later on.
Documentation: College management systems often require extensive documentation for
compliance auditing, and future maintenance. The Waterfall Model emphasizes documentation at each
stage ensuring that all aspects of the system are well-documented throughout the development lifecycle.

Sequential Progression: The Waterfall Model's sequential progression from one phase to the next
well with the development of a college management system. Each phase builds upon the outputs of the ,
previous phase, allowing for a structured and systematic approach to development.

In conclusion, the Waterfall Model is best suited for developing a college management system due to
emphasis on clear requirements, comprehensive planning, documentation, sequential progression,
predictability, and control. It provides a structured framework that aligns well with the nature of such
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

projects, ultimately leading to a successful and efficient development process.

Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 12 - Explain with reason which model is best suited for the product
College Management System Protocol
1. User Authentication:
All users accessing the CMS must authenticate themselves using valid credentials (e.g., username and
password).
The system should support role-based access control, including roles such as students, faculty,
administrators, and staff.

2. Student Management:
Students can register for courses, view their academic records, grades, and attendance.
They can also update their personal information (e.g., contact details, address) as needed.
Students should be able to access course materials, assignments, and announcements.

3. Faculty Management:
Faculty members can upload course materials, create assignments, and grade student submissions.
They can also view their teaching schedule, student enrollment lists, and academic records of their student
Faculty members may also communicate with students through the system, such as sending
announcements or messages.

4. Course Management:
The system should allow administrators to create and manage courses, including defining course schedules
, prerequisites, and maximum enrollment limits.
Course materials, syllabi, and resources should be easily accessible to both faculty and students.
Students should be able to register for courses, view available courses, and drop courses if necessary.

5. Attendance Management:
Faculty members can take attendance for their classes, either manually or using automated systems (e.g.,
RFID cards, biometric scanners).
Students can view their attendance records and monitor their attendance status for each course.

6. Examination and Grading:

The system should support the scheduling and management of examinations, including setting exam dates,
venues, and generating seating arrangements.
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Faculty members can upload exam questions, conduct exams, and enter grades for student submissions.
Students can view their exam schedules, access past exam papers, and receive their grades once they are
released.

7. Administrative Functions:
Administrators have access to all features of the CMS and can perform tasks such as user management,
system configuration, and generating reports.
They can also handle administrative processes like admissions, fee payments, and academic planning.

8. Communication and Notifications:

The system should facilitate communication between users through features like messaging, discussion
forums, and announcements.
Users should receive notifications for important events, deadlines, or updates related to courses,
examinations, and administrative matters.

9. Data Security and Privacy:

The CMS should adhere to data security standards and regulations to ensure the confidentiality, integrity,
and availability of user data.
Access to sensitive information should be restricted based on user roles and permissions.

10. Maintenance and Support:

Regular maintenance and updates should be performed to ensure the smooth functioning of the CMS.
Technical support should be available to assist users with any issues or queries they encounter while using
the system.
This protocol outlines the basic functionalities and features of a College Management System, providing
guidelines for its development, implementation, and usage. Depending on the specific requirements and
complexities of the institution, additional features and customization may be necessary.
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

Practical 13: Use LOC, FP and Cyclomatic Complexity Metric of above-mentioned problem

Lines of Code (LOC):

LOC is a simple metric that counts the number of lines in the source code of a software system. However,
it's important to note that LOC can vary greatly depending on the programming language, coding style, and
level of abstraction.
For a CMS, the LOC can vary significantly based on factors such as:
Number of modules (e.g., user authentication, student management, course management, etc.).
Complexity of business logic and data processing.
Integration with external systems or libraries.
Use of frameworks or pre-built components.
A rough estimate for a medium-sized CMS implemented in a high-level language like Python or Java could
range from several thousand to tens of thousands of lines of code.

Function Points (FP):

FP is a software metric used to measure the size and complexity of a software system based on its
functionality. It considers the inputs, outputs, inquiries, interfaces, and internal logical files of the system.

For a CMS, the function points could be calculated based on:

Number of user interactions (e.g., logging in, registering for courses, viewing grades).
Number of data entities managed by the system (e.g., students, courses, faculty).
Number of external interfaces (e.g., integration with other systems or databases).
Complexity of business rules and processes.
The FP count provides a standardized measure of the system's size, which can be used for estimating effort,
cost, and schedule for development and maintenance activities.

Cyclomatic Complexity:
Cyclomatic Complexity is a software metric used to measure the complexity of a program's control flow
graph. It provides insight into the number of independent paths through the code and is often used as an
indicator of code readability, maintainability, and testability.
Software Engineering Laboratory (UGCA1924) Gaurav: 2202001

For a CMS, the Cyclomatic Complexity could be calculated for individual modules or functions within the
system. Higher complexity values indicate more complex control flow and potentially more difficult-to-
understand code.

Areas of the CMS with potentially higher Cyclomatic Complexity could include:
Authentication and authorization logic.
Business rules for course registration, grading, and scheduling.
Error handling and exception paths.
Complex algorithms or decision-making processes.
Managing Cyclomatic Complexity is important for maintaining code quality and reducing the risk of defects
and errors.

These metrics provide valuable insights into different aspects of the CMS, helping developers and
stakeholders assess its size, complexity, and maintainability. However, it's important to interpret these
metrics in context and use them as part of a broader approach to software development and quality
assurance.