МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

Ордена Трудового Красного Знамени федеральное государственное бюджетное образовательное учреждение высшего образования

Московский технический университет связи и информатики

(МТУСИ)

Кафедра «Сетевые информационные технологии и сервисы»

Отчет по курсовому проектированию

по дисциплине «Методы и средства проектирования информационных систем и технологий»

Выполнили:

студенты группы БФИ2203

Белов З. Д.

Воронков М. Д.

Козлова Я. В.

Мячина Л. А.

Сальников Д. С.

Шагинов В. Е.

Руководитель:

Рахмани Д.

Москва, 2025 г.

Проектирование системы управления арендуемой недвижимостью

1. Предварительное описание

Арендодатели и управляющие компании нуждаются в автоматизированной системе для управления сдачей квартир, коммерческих помещений и другой недвижимости в аренду. Система должна обеспечивать удобный интерфейс для арендодателей, арендаторов и администраторов, а также поддержку онлайн-платежей, контроля задолженностей и автоматического продления аренды.

Каждый новый арендатор регистрируется в системе, указывая свои контактные данные, предпочтения по арендуемому объекту и загружая необходимые документы (паспорт, договор аренды). После регистрации он получает доступ к каталогу доступных помещений, где может просматривать описание, стоимость аренды, фотографии и условия договора. Выбрав объект, арендатор подает заявку, после чего владелец недвижимости подтверждает или отклоняет ее.

Оплата аренды производится онлайн через встроенную платежную систему или банковским переводом. Система автоматически уведомляет арендатора о приближении срока оплаты и фиксирует задолженности. Если платеж не поступает вовремя, система может начислить штрафы или временно ограничить доступ к определенным сервисам (например, парковке или коммунальным услугам).

Арендодатели могут управлять своими объектами, изменять условия аренды, добавлять новые объявления и отслеживать платежи. В случае необходимости они могут разорвать договор аренды или предложить продление аренды на новых условиях. Администратор системы управляет всеми транзакциями, следит за своевременностью оплат и помогает пользователям при возникновении спорных ситуаций. Также он может формировать отчеты о загруженности объектов, общей выручке и задолженностях.

Система должна обеспечивать безопасность данных арендаторов, поддержку автоматического выставления счетов и возможность интеграции с государственными реестрами недвижимости.

2. Выделение прецедентов

2.1. Определение рамок системы

Чтобы точнее установить рамки проектируемой системы, определим, за что система не должна отвечать:

1. Проверка правдоподобности внешнего вида объекта.

2. За работы встроенной платежной системы.(обработка платежей)

3. За условия договора аренды.

Мы определили, за что система не отвечает, иначе говоря, – внешние вспомогательные исполнители.

2.2. Определение основных исполнителей и задач

Проанализировав описание выделили следующих исполнителей:

1. Первый основной исполнитель - арендодатель;

2. Второй основной исполнитель - арендатор;

3. Вспомогательный исполнитель - системный администратор;

После определения основных исполнителей необходимо провести анализ каждого из них для определения требований, которые они могут предъявить.

Таблица 2.2.1

Основные исполнители и задачи

Исполнители	Задачи
Арендодатели	Добавляют новые объявления о сдаче объектов Отслеживают платежи арендаторов. Подтверждают или отклоняют заявки арендаторов на аренду.
Арендаторы	Регистрируются в системе Загружает необходимые документы Просматривают описание объектов, стоимость аренды, фотографии и условия договора Производят оплату аренды онлайн
Администратор системы	Помогает пользователям при возникновении спорных ситуаций Следит за транзакциями и за своевременностью оплат Обеспечивают контроль за работой системы

В системе, которую мы разрабатываем, каждая задача пользователя имеет свой прецедент, название которого начинается с существительного, описывающего действие. Из анализа таблицы следует, что в системе присутствуют три исполнителя: арендодатель, арендатор и администратор системы. Следовательно, мы определяем прецеденты, связанные с задачами этих участников.

Составим перечень задач и прецедентов в виде таблицы.

Таблица 2.2.2

Основные задачи и прецеденты

Задача	Прецедент
Добавляют новые объявления о сдаче объектов	Добавление объявлений
Отслеживают платежи арендаторов	Отслеживание платежей
Подтверждают или отклоняют заявки арендаторов на аренду	Подтверждение заявок
Регистрируются в системе	Регистрация в системе
Просматривают описание объектов, стоимость аренды, фотографии и условия договора	Просмотр информации об объектах
Производят оплату аренды онлайн	Оплата аренды
Обеспечивают контроль за работой до системы	Контроль работы системы

В таблице “Ранжирования прецедентов” мы должны определить, какой прецедент имеет более высокий ранг. Ранжирование прецедентов позволяет определить приоритеты и последовательности выполнения различных сценариев или задач. Это позволит нам оптимизировать подход к созданию системы, а также поможет повысить качество работы системы, сосредоточив усилия на наиболее важных прецедентах. Для ранжирования прецедентов, сравним их по 3 параметрам: важность, объем и сложность. Сложность оценивается на основе количества шагов, необходимых для выполнения прецедента, и степени детализации, которую требуется добавить в систему для поддержки этого прецедента. Способ ранжирования может быть разный (например, прецеденты ранжируются по 5-ти бальной шкале сверху вниз от наиболее до наименее значимого).

Составим ранжировку прецедентов в виде таблицы, сама таблица представлена в таблице 2.2.3.

Таблица 2.2.3

Ранжирование прецедентов

Прецеденты	Важность	Объем	Сложность	Ранг
Добавление объявлений	10	9	9	9,3
Регистрация в системе	10	7	8	8,3
Контроль работы системы	7	8	6	8
Оплата аренды	8	8	8	8
Подтверждение заявок	8	6	7	7
Просмотр информации об объектах	9	3	6	6
Отслеживание платежей	8	5	4	5,6

Исходя из параметров, можно сказать, что прецедент “Регистрация в системе” имеет наиболее высокий ранг из-за его высокой важности, объема и сложности.

Обоснование оценки прецедентов:

1. Добавление объявлений

• Важность (10): Это ключевая функция системы, так как без объявлений система теряет смысл.

• Объем (9): Требует ввода данных (заголовок, описание, фото), но меньше, чем регистрация.

• Сложность (9): Необходимо реализовать загрузку и хранение файлов (фото объявлений). Требуется валидация данных (например, проверка на запрещенные слова). Возможна необходимость модерации объявлений перед публикацией.

2. Регистрация в системе

• Важность (10): Регистрация — это основа системы. Без неё пользователи не смогут получить доступ к функционалу.

• Объем (7): Требует ввода данных пользователя (имя, email, пароль), проверки данных (валидация email, проверка уникальности), а также интеграции с базой данных.

• Сложность (8): Необходимо реализовать безопасное хранение паролей и конфиденциальной информации пользователя (хэширование). Требуется интеграция с базой данных для хранения данных пользователей. Возможна необходимость подтверждения email (отправка письма с подтверждением). Нужно предусмотреть обработку ошибок (например, если email уже занят).

3. Контроль работы системы

• Важность (7): Контроль работы системы важен для обеспечения стабильности, но это больше внутренний процесс, который не напрямую влияет на пользователей.

• Объем (8): Требует мониторинга множества параметров системы (производительность, ошибки, логи и т.д.).

• Сложность (6): Необходимо реализовать сбор и анализ данных о работе системы. Требуется интеграция с инструментами мониторинга (например, Grafana, Prometheus). Сложность ниже, чем у регистрации, так как контроль системы не требует сложной логики взаимодействия с пользователем и обеспечения безопасности.

4. Оплата аренды

• Важность (8): Оплата — это ключевой процесс, связанный с финансами. Ошибки здесь могут привести к серьезным последствиям, таким как потеря денежных средств пользователей.

• Объем (8): Требует интеграции с платежными системами, обработки транзакций, учета платежей и генерации чеков.

• Сложность (8): Необходимо обеспечить безопасность платежей (SSL, шифрование данных). Требуется интеграция с внешними платежными системами (например, Stripe). Нужно предусмотреть обработку ошибок (например, если платеж не прошел).

5. Подтверждение заявок

• Важность (8): Это важный процесс, связанный с обработкой запросов пользователей.

• Объем (6): Требует проверки данных и принятия решения (одобрить или отклонить заявку).

• Сложность (7): Необходимо реализовать логику принятия решений (например, на основе правил системы). Требуется уведомление пользователей о статусе заявки. Сложность ниже, чем у оплаты, так как не требуется интеграция с внешними системами.

6. Просмотр информации об объектах

• Важность (9): Это важная функция для пользователей, но она не критична для работы системы в целом.

• Объем (3): Требует только отображения данных, которые уже хранятся в системе.

• Сложность (6): Необходимо реализовать поиск и фильтрацию данных. Требуется оптимизация запросов к базе данных для быстрого отображения информации. Сложность ниже, так как это пассивная операция (только чтение данных).

7. Отслеживание платежей

• Важность (8): Это важно для пользователей и для учета финансов.

• Объем (5): Требует отображения истории платежей и их статусов.

• Сложность (4): Необходимо реализовать отображение информации из базы данных. Требуется минимальная обработка данных (например, фильтрация по дате). Сложность низкая, так как это в основном задача чтения данных.