Риэлтерская деятельность

Риэлтерская деятельность

Введение

Риэлтерская деятельность - это профессиональная деятельность по оказанию услуг при совершении операций с объектами недвижимого имущества за определенное вознаграждение, которая осуществляется на постоянной основе. Риэлтерской деятельностью также признается другая коммерческая профессиональная деятельность на рынке недвижимого имущества.

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

Целью данного курсового проекта, является разработка информационной системы, в которой будут содержаться данные о недвижимости, которая была выставлена на продажу в риэлтерском агентстве.

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

Для достижения поставленной цели необходимо решить следующие задачи:

·Необходимо рассмотреть основные задачи ИС

·Провести анализ требований проектируемой ИС

·Наглядно отобразить проект ИС

·Проанализировать и определить оценку трудоемкости проекта

Глава 1. Постановка задачи

В курсовой работе требуется разработать информационную систему (ИС) «Риэлтерское агентство» данная ИС обязана выполнять функции:

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

.Вести учет клиентов, желающих приобрести квартиру. При этом клиент:

имеет возможность авторизоваться в системе (логин, пароль);

просмотреть варианты (район, кол-во комнат, тип дома, цена и т.д.).

.Вести учет договоров, заключенных с риэлтерским агентством.

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

.Формировать отчеты для администрации агентства о проданных квартирах, оплате по договорам, отчет о клиентах, отчет о соотношении выполненных или невыполненных договоров.

Глава 2. Разработка требований

.1 Глоссарий

Для разрабатываемой ИС определим словарь терминов - глоссарий.

Бухгалтер - специалист, работающий по системе учета в соответствии с действующим законодательством.

Специалист - уровень высшего образования, по окончании которого присваивается квалификации специалиста.

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

Отчет - документ, отображающий деятельность элемента системы за определенный срок.

Терминал ИС - устройство, используемое для взаимодействия пользователя с компьютером.

2.2 Диаграмма вариантов использования

Для разработки диаграмм, описывающих проектируемую информационную систему используется технология RUP (Rational Unified Process). Диаграмма вариантов использования строится в пакете IMB Rational Rose.

Для данной курсовой работы была создана диаграмма вариантов использования. На рисунке 1 показано, что с ИС «Риэлтерское агентство» взаимодействуют 3 актера, которые выполняют определенные функции. Таким образом, «Специалист» выполняет: учет списка квартир, составления отчетов. «Бухгалтер» выполняет учет денежных средств в системе.

«Рисунок 1. Диаграмма вариантов использования»

2.3 Нефункциональные требования

Нефункциональные требования к данной курсовой работе были сформированы в пакете IBM Rational RequisitePro, который входит в состав Rational Rose. Нефункциональные требования описывают технические характеристики системы, которые должны быть реализованы в ИС.

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

«Рисунок 2. Нефункциональные требования»

2.4 Функциональные требования

Функциональные требования описывают наличие необходимых элементов при выполнении определенных функций.

Для данного курсового проекта были созданы функциональные требования к проектируемой системе. Функциональные требования ВИ, а именно: процесс аутентификации пользователей, просмотр вариантов квартир, подписание договора на покупку, учет договоров, формирование отчетов. Отдельно можно сказать про функциональные требования к ВИ «Составление отчетов». Так как составление отчетов разных видов, которые описаны в задании относятся к одной функции, то и все необходимые функциональные требования ко всем видам отчетов описаны в данных функциональных требованиях.

«Рисунок 3. Функциональные требования»

.5 Сценарий варианта использования

Описание сценариев вариантов использования.

Таблица 1. Сценарий выполнения варианта использования «Процесс аутентификации пользователя»

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

.Клиент авторизуется в системе

А1. Клиент не зарегистрированный в системе

.ИС предлагает ввести логин и пароль

.Клиент вводит логин и пароль для входа в систему

А2. Логин и пароль не правильные

.ИС отображает главное меню

Исключения из сценария А1.

.ИС предлагает зарегистрироваться в системе

.ИС предоставляет анкету для заполнения

.Клиент заполняет анкету

.ИС сохраняет данные и формирует «учетную запись»

.ИС уведомляет о создании учетной записи

Исключения из сценария А2.

.ИС отображает информацию о неправильно введенном логине и пароле

.ИС предлагает заново ввести логин и пароль

.Клиент вновь вводит логин и пароль

.Вводит логин и пароль 5 раз подряд неправильно

.ИС блокирует данного пользователя и предлагает отправить логин и пароль по электронной почте

Таблица 2. Сценарий выполнения варианта использования «Просмотр вариантов квартир»

Вариант использованияПросмотр вариантов квартирАктерыКлиент, ИСЦельВыбрать квартируОписание действияКлиент просматривает предложенные варианты квартир для выбора определенной

.Клиент заходит в раздел с вариантами квартир

.ИС формирует список квартир для просмотра

А1. ИС не может найти квартиры для продажи

.Клиент просматривает квартиру

.ИС предоставляет описание выбранной квартиры

.ИС подбирает похожие варианты

.ИС предлагает посмотреть их клиенту

.ИС предоставляет описание подобранных квартир

.ИС предлагает заполнить требования для просмотра квартир по выбранным параметрам

.Клиент заполняет параметры

А2. Требования сформированы неверно

.ИС выдает список квартир согласно выбранным параметрам

.Клиент просматривает варианты предложенные системой

.Клиент выбирает квартиру для просмотра

.ИС предоставляет описание выбранной квартиры

.Клиент выбрал квартиру

Исключения из сценария А1.

.ИС посылает запросы на сервер для обновления базы квартир

.ИС принимает информацию с сервера

.ИС выдает данные клиенту для просмотра

Исключения из сценария А2.

.ИС предлагает клиенту заполнить требования заново

.Клиент заполнил требования

.ИС проверяет правильность заполнения данных клиентом

.ИС выдает список квартир согласно выбранным параметрам

Таблица 3. Сценарий выполнения варианта использования «Подписание договора на покупку»

Вариант использованияПодписание договора на покупкуАктерыКлиент, ИСЦельПодписать договор на приобретениеОписание действияКлиент доводит сведения до специалиста о том, что он готов приобрести данную квартиру

.Клиент посмотрел квартиру согласно его предпочтениям

.Специалист подготовил пакет документ

.Бухгалтер проговорил стоимость квартиры с клиентом

.Клиент одобрил стоимость квартиры и стоимость услуг риэлтерского агентства

.Бухгалтер пункт меню договора

.ИС предоставляет список существующих договоров

.Бухгалтер открывает определенный договор и подготавливает его к подписанию

.ИС распечатывает договор

.Специалист проверяет правильность договора

А1. Договор является не верно оформлен

.Специалист передает договор клиенту для ознакомления

.Клиент проверяет правильность личных данных

А2. Данные клиента введены не верно

.Клиент и специалист подписывают договор

Исключения из сценария А1.

.ИС предлагает редактировать данный договор

.Бухгалтер редактирует договор

.Специалист проверяет договор на наличие ошибок

.Распечатка договора

Исключения из сценария А2.

.ИС предлагает редактировать договор

.Специалист редактировать договор

.ИС предлагает сохранить копию договора в системе

.ИС предлагает распечатать договор

Таблица 4. Сценарий выполнения варианта использования «Учет договоров»

Вариант использованияУчет договоровАктерыБухгалтер, Специалист, ИСЦельУчет договоровОписание действияИС предлагает ввести учет договоров бухгалтеру и специалисту

.ИС предлагает сохранить копию договора для его учета

.Специалист предоставляет ИС договора для обработки

.Бухгалтер предоставляет ИС договора для обработки

.ИС обрабатывает полученные договора

.ИС сохраняет договора в базу

Таблица 5. Сценарий выполнения варианта использования «Формирование отчетов»

Вариант использованияФормирование отчетовАктерыБухгалтер, Специалист, ИСЦельФормирование отчетовОписание действияИС формирует отчеты

.Бухгалтер выбирает пункт главного меню: Отчетность

.ИС отображает меню данного раздела (отчеты, создать)

.Бухгалтер выбирает пункт «Создать»

.ИС создает документ отчета для заполнения

.Бухгалтер заполняет документ необходимыми данными

.Специалист выбирает пункт главного меню: Отчетность

.ИС отображает меню данного раздела (отчеты, создать)

.Специалист выбирает пункт «Создать»

.ИС создает документ отчета для заполнения

.Специалист заполняет документ необходимыми данными

.ИС сохраняет отчеты в раздел «Отчеты»

Глава 3. Анализ системы

.1 Диаграмма деятельности

недвижимость риэлтерский информационный

Для проектируемой ИС «Риэлтерское агентство» была сделана диаграмма деятельности.

Эта диаграмма показывает динамику проекта и представляет собой схему потоков управления в системе от действия к действию. Она строится для всей системы в целом. В начале клиент просматривает варианты квартир, и выбирает устраивающий вариант. После чего специалист составляет договор на покупку. Затем отчеты поступают бухгалтеру, где он должен проверить их.

Рисунок 4. Диаграмма деятельности

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

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

Рисунок 5. Диаграмма последовательности

Глава 4. Проектирование

.1 Диаграмма классов

Для проектируемой системы была создана диаграмма классов в пакете IBM Rational Rose. Данная диаграмма показывает, какие классы взаимодействуют между собой в ИС.

В ИС «Риэлтерское агентство» всего 5 классов: User, Flats, Account of contracts, purchase agreement, Reports.

Рисунок 6. «Диаграмма классов»

4.2 Диаграмма состояний

Диаграмма состояний отличается от других тем, что описывает процесс изменения состояний только одного экземпляра определенного класса - одного объекта, причем объекта реактивного, то есть объекта, поведение которого характеризуется его реакцией на внешние события. Данная диаграмма построена для выполнения функции «Подписание договора на покупку»

Рисунок 7. «Диаграмма состояний»

4.3 Диаграмма компонентов

Для проектируемой системы была создана диаграмма компонентов, показывающая из каких компонентов состоит ИС. В ИС существуют 3 основных модуля: Mainflat, Mainspecialist, Авторизация. К ним подключены 4 библиотеки, а к данным этих библиотек, хранилища данных.

Рисунок 8. «Диаграмма компонентов»

4.4 ER - диаграмма

Для проектируемой системы была создана ER - диаграмма. В ней отображается концептуальная модель планируемой базы данных, которая будет использоваться в ИС.

Диаграмма включает в себя все сущности, а так же связи между ними и тип взаимодействия.

Рисунок 9. «ER - диаграмма»

4.5 Интерфейс

Для проектируемой системы был создан интерфейс. Набор интерфейсов отображает: главное меню программы, окно для регистрации, просмотр вариантов квартир, подписание договора с клиентом

Рисунок 10. «Главное меню программы»

Рисунок 11. «Окно регистрации входа в программу»

Рисунок 12. «Просмотр вариантов квартир»

Рисунок 13. «Подписание договора с клиентом»

Глава 5. Оценка трудоемкости

.1 Определение весовых показателей действующих лиц

Все действующие лица разделяются на три типа: простые, средние, сложные.

Простое действующее лицо представляет внешнюю систему с определенным программным интерфейсом. Среднее действующее лицо представляет внешнюю систему, взаимодействующую с данной системой посредством протокола. Так же действующее лицо представляет личность, пользующуюся текстовым интерфейсом. Сложное действующее лицо представляет личность, пользующуюся графическим интерфейсом.

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

Таблица 6. Весовые показатели действующих лиц

Тип действующего лицаВесовой коэффициентПростой1Средний2Сложный3

Таблица 7. Действующие лица и основные показатели

Действующие лицаВесовой показательКлиент1Специалист2Бухгалтер1

Таким образом, общий весовой показатель равен:

А = 1*2 + 2*1 = 4

.2 Определение весовых показателей вариантов использования

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

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

Таблица 8. Весовые показатели вариантов использования

Тип варианта использованияОписаниеВесовой коэффициентПростой 3 ≤ Т5Средний 4 ≤ Т ≤ 710Сложный Т ≥ 715

Типы вариантов использования

Варианты использованияТипАвторизация в системеПростойКаталог вариантов квартир для просмотраПростойПодписание договора для покупкиСреднийУчет договоровСреднийФормирование отчетовПростой

Таким образом, общий весовой показатель равен:

UC = 3*5+2*10 = 35

В результате получаем показатель UUCP:

UUCP = A + UC = 4 + 35 = 39

.3 Определения технической сложности проекта

Техническая сложность проекта вычисляется с учетом показателей технической сложности. Каждому показателю присваивается знание Ni в диапазоне от 0 до 5.

Таблица 9. Показатели технической сложности проекта

ПоказательОписаниеВесовой показательЗначимостьЗначение с весом учетаT1Распространенная система236T2Производительность3515T3Работа онлайн122T4Сложность обработки данных339T5Повторное использование кода4416T6Простота установки0,531,5T7Простота использования3412T8Переносимость339T9Простота изменений 4520T10Параллелизм236T11Безопасность3412T12Допуск внешних пользователей122T13Требования к обучению122∑112,5

Таким образом, общий показатель равен:

TCP = 0,6 + (0,01*112,5) = 1,725

5.4 Определение уровня квалификации разработчиков

Уровень квалификации работников вычисляется с учетом следующих показателей. Каждому показателю присваивается значение в диапазоне от 0 до 5. Для показателей F1-F4 0 - отсутствие, 3 - средний уровень сложности, 5 - высокий уровень сложности. Вес от -1 до 2.

ПоказательОписаниеВесЗначениеЗначение с учетом весаF1Знакомство с технологией1,523F2Опыт разработки приложений122F3Опыт использования объектно - ориентированного подхода236F4Наличие ведущего аналитика0,522F5Мотивация133F6Стабильность требований236F7Частичная занятость-100F8Сложные языки программирования122∑24

EF = 1,4 + (- 0,03 * 24) = 0,68

В результате получаем окончательное значение UCP.

UCP = UUCP * TCF * EF = 39 *1,725 * 0,68 = 45,75

Заключение

В курсовой работе была спроектирована ИС «Риэлтерское агентство». Проект описывался следующими диаграммами: диаграмма вариантов использования, диаграмма деятельности, диаграмма последовательности, диаграмма классов, диаграмма состояния, диаграмма компонентов, ER- диаграмма.

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

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

Таким образом, из вышеперечисленного можно сказать, что ИС «Риэлтерское агентство» готова для внедрения.

Список литературы

1.Свободная энциклопедия http://ru.wikipedia.org

.Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для вузов/ Под. ред.А.Д. Хомоненко. - М.: Бином-Пресс, 2006.

.Рудикова Л.В., Базы данных. Разработка приложений. - СПБ.: БХВ-Петербург, 2006.

.Microsoft Access 2007. Разработка приложений на реальном примере. Изд. БХВ - Петербург, 2007.

.Microsoft SQL Server 2005. Реализация и обслуживание. Учебный курс Microsoft / Пер. с англ. - М.: "Русская Редакция", СПб.: "Питер", 2007.

.Велинг Л. Томсон Л. MySQL. Учебное пособие. - М.: Издательский дом Вильямс, 2005.