Преподаватель который помогает студентам и школьникам в учёбе.

Разработка проекта информационной системы учета риэлтерских операций

Содержание:

Введение

Объект исследования - процесс учета операций с недвижимостью в агентстве недвижимости. Предмет исследования - информационная система учета операций с недвижимостью в агентстве недвижимости.

Цель работы - проектирование информационной системы учета операций с недвижимостью с помощью Rational Rose, pgModeler, PhpStorm, Laravel, Microsoft Visio с использованием базы данных PostgreSQL.

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

Методы исследования - функциональное моделирование, информационное моделирование.

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

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

1. Теоретические основы проектирования информационной системы учета операций с недвижимостью

1.1 Теоретические основы учета операций с недвижимостью

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

Риэлторские услуги — это услуги, которые оказываются при осуществлении риэлторской деятельности.

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

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

Первая группа состоит из риэлторских услуг, которые риэлтор проводит с недвижимым имуществом, но эти сделки не связаны по его отчуждению, сдачи в аренду, наем и т.д.

Вторая группа включает в себя услуги риэлтора по участию имущества "недвижимого и жилого" в гражданском обороте.

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

Существуют несколько основных видов деятельности риэлтора. Например, деятельность риэлтора в качестве:

- агента или поверенного;

- брокера;

- дилера;

- посредника при заключении сделок с недвижимым имуществом или правами на него между третьими лицами;

- по организации торговли недвижимым имуществом;

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

- по доверительному управлению недвижимым имуществом;

- по предоставлению консультационных услуг, услуг по изучению конъюнктуры рынка, иных возмездных услуг, сопутствующих гражданскому обороту недвижимого имущества [1].

Рассмотрим такие виды риэлторских услуг, как покупка, продажа и аренда помещения.

Основной формой выражения таких взаимоотношений является договор.

Данные операции с недвижимостью подразделяются условно на 5 этапов:

Получение заявки на предоставление риэлторской услуги.

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

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

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

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

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

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

Если риэлтор представляет интересы покупателя, его функции заключаются в следующем:

- проведение маркетингового анализа рынка недвижимости;

- организация просмотра выбранных вариантов;

- сбор документов об объекте недвижимости;

- организация переговоров;

- предоставление отчета заказчику о проделанной работе и информирование о степени готовности всех субъектов к оформлению сделки.

Если риэлтор представляет интересы продавца, то его функции состоят в организации:

- рекламы объекта;

- показов объектов потенциальным покупателям;

- переговоров между покупателями и продавцом.

4. Юридическое сопровождение сделки, определение ее условий и порядка взаиморасчетов.

5. Оформление сделки с недвижимостью и оплата услуг риэлтору.

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

1. подписание договора и подача документов на государственную регистрацию сделки с недвижимостью;

2. передача денег после получения свидетельства о регистрации;

3. приемка-передача объекта;

4. оплата услуг риэлтора за выполненную работу [2].

1.2 Концепция информационной системы учета операций с недвижимостью

Проблемы, которые возникают из-за отсутствия информационной системы учёта операций с недвижимостью:

- отсутствует электронный документооборот;

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

- помещения на продажу/аренду/покупку хранятся в базе не отсортированные, что затрудняет поиск нужного помещения;

- есть риск совершения сделок «нечестными» риэлтерами в обход агентства.

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

- продаже помещения;

- покупке помещения;

- аренде помещения.

2. Разработка концептуальной модели информационной системы

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

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

В нашем случае использованы следующие стереотипы актеров:

- "Клиент" и "Риэлтор" - бизнес-актёры (business actor) позволяют представить исполнителей бизнес-функций, связанного с работой информационной системы.

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

Моделируемая система включает в себя пять основных вариантов действий: покупка помещения, аренда помещения, продажа помещения, поиск помещения по базе данных, поиск клиента (для осуществления продажи помещения).

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

Связи между классами (ассоциации) определяются на основе диаграмм взаимодействия. Если два объекта взаимодействуют (обмениваются сообщениями), между ними должна существовать связь (путь взаимодействия). Для ассоциаций задаются множественность и, возможно, направление навигации. Могут использоваться множественные ассоциации, агрегации и классы ассоциаций.

Были использованы следующие виды связи:

- ассоциации - направление стрелки позволяет понять, кто инициирует коммуникацию. Ассоциация направлена от актёров Клиент и Риелтор к вариантам использования покупка помещения, аренда помещения, продажа помещения.

- отношение зависимости со стереотипом <include>. Применяется, когда один из прецедентов использует другой. Направлено от вариантов использования покупка помещения и аренда помещения к варианту использования поиск помещения по базе данных и от варианта использования продажа помещения к прецеденту поиск клиента.

2.2 Диаграмма классов

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

Для диаграммы классов проектируемой были системы разработаны следующие классы:

- клиент;

- договор;

- риэлтор;

- список условий;

- условия;

- помещение.

Отношения между классами выглядят следующим образом:

- классы Клиент и Договор - отношение ассоциации. Один клиент может заключить один и более, каждый договор оформляется только для одного клиента, поэтому кратность связи со стороны класса Клиент - 1, со стороны Договор - 1..n (один ко многим);

- классы Договор и Риелтор - отношение ассоциации. Один риэлтор может оформить один и более, каждый договор оформляется только одним риэлтором, поэтому кратность связи со стороны класса Риэлтор - 1, со стороны Договор - 1..n (один ко многим);

- классы Услуга и Условия - отношение ассоциации. Но основе одной услуги формируется несколько условий, поэтому кратность связи со стороны класса Условие - n (много), со стороны Услуга - 1.

- классы Договор и Условия - отношение ассоциации. Один договор формирует несколько условий, 1 условие относится к одному договору, связи со стороны класса Договор - 1, со стороны Условия - n (много);

- классы Условия и Помещение - отношение ассоциации. Одному условию может соответствовать несколько помещений, связи со стороны класса Договор - 1, со стороны Условия - n (много);

- классы Помещение и Адрес – отношение ассоциации. Одному адресу может соответствовать несколько адресов (в случае продажи или аренды комнаты, а также в случае сделки по коммерческой недвижимости). Связь один ко многим.

2.3 Диаграмма действий

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

Рассмотрим процесс риэлторской деятельности:

- клиент обращается в риэлторскую компанию и подаёт заявку;

- риэлтор регистрирует заявку в БД;

- риэлтор в базе данных ищет подходящее помещение, которое удовлетворяет условиям и требованиям клиента;

- риэлтор демонстрирует помещение клиенту;

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

- риэлтор заключает необходимые договора с клиентом по выбранному помещению;

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

2.4 Диаграмма последовательности

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

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

- клиент;

- риэлтор;

- условия;

- список условий;

- помещение;

- договор.

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

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

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

Для диаграммы компонентов были реализованы следующие классы:

- для компоненты Клиенты - класс Clients;

- для компоненты Недвижимость- класс RealEstate;

- для компоненты Договоры - класс Contract;

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

Программный код был написан в IDE PhpStorm для выполнения в среде PHP 7.3 с использованием фреймворка Laravel 7.

3. Разработка логической и физической моделей базы данных информационной системы

3.1 Разработка логической модели ИС

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

На основе ситуации описания проекта была спроектирована модель базы данных и составлена схема логической модели типа Database Model Diagram в Microsoft Visio. Данными для построения логической модели информационной системы являются знания, отображённые в разделе Диаграмма классов. Она будет включать те же сущности (Приложение 2). Логическая модель изображена на (Приложение 5).

- классы Клиент и Договор - отношение композиции. Один клиент может заключить один или несколько договоров, каждый договор оформляется только для одного клиента, исходя из этого кратность связи со стороны класса Клиент - 1, со стороны Договор - 1..n (один ко многим);

- классы Договор и Риелтор - отношение композиции. Один риэлтор может оформить один или несколько договоров, каждый из договоров оформляется только одним риэлтором, исходя из этого кратность связи со стороны класса Риэлтор - 1, со стороны Договор - 1..n (один ко многим);

- классы Услуга и Условия - отношение композиции. Но основе одной услуги формируется несколько условий, исходя из этого кратность связи со стороны класса Условие - n (много), со стороны Услуга - 1;

- классы Договор и Условия - отношение композиции. Один договор формируется на основе нескольких условий, связи со стороны класса Договор - 1, со стороны Условия - n (много);

- классы Условия и Помещение - отношение композиции. Одному условию может соответствовать несколько помещений, связи со стороны класса Договор - 1, со стороны Условия - n (много);

Зададим индексирование поля Номер договора, в сущности, Договор (Приложение 6).

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

3.1 Разработка физической модели ИС

Физическая модель данных зависит от конкретной используемой СУБД, фактически являясь отображением системного каталога.

После преобразования логической модели в физическую имеем следующую модель Физическая модель изображена на (Приложение 6).

С помощью pgModeler были сгенерированы SQL запросы для создания таблиц в БД PostgreSQL 10. (Приложение А)

Схема БД изображена на (Приложение 7).

3.3 Формирование таблицы описания документов и разработка форм входных и выходных документов в IDE PhpStorm с использованием фреймворка Laravel

Приложение 7

Главная страница информационной системы - отсюда можно попасть в остальные её компоненты.

Для создания страницы и всей системы использовались пакеты composer:

jeroennoten/laravel-adminlte;
laravel/framework;
laravel/ui.

Список клиентов. Поиск информации осуществляется SQL-запросом SELECT * FROM clients;

Список сотрудников. Поиск информации осуществляется SQL-запросом SELECT * FROM realtors;

Список недвижимости. Поиск осуществляется SQL-запросом SELECT real_estate.id, real_estate.address, conditions.rooms, conditions.price FROM real_estae LEFT JOIN conditions ON real_estate.id=conditions.real_estate;

Список догворов. Поиск осуществляется SQL-запросом SELECT * FROM contracts LEFT JOIN conditions ON contracts.id_condition=conditions.id;

Форма договора показывает информацию о заключенных договорах их условиях, так же даёт возможность добавить новые. Поиск информации осуществляется SQL-запросом: SELECT * FROM contracts LEFT JOIN conditions ON contracts.id_condition=conditions.id;

Заключение

В ходе работы был рассмотрен процесс деятельности агентства недвижимости и его.

Основой для создания информационной системы послужили проблемы предметной области. Для разработки проекта программных приложений использовались Rational Rose, pgModeler, PhpStorm, Laravel, Microsoft Visio с использованием базы данных PostgreSQL и других вспомогательных инструментов, например composer. В результате работы была построена концептуальная, логическая и физическая модели информационной системы.

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

Также были спроектированы логическая и физическая модели информационной системы. На основании физической модели была сгенерирована база данных.

С помощью IDE PhpStorm для среды PHP было разработано программное обеспечение для работы с базой данных PostgresSQL. Приложение включает в себя: списки, отображающие клиентов, сотрудников агентства недвижимости, и договоров; формы для создания/редактирования договоров и их условия, добавления клиентов, добавления сотрудников и добавления недвижимости.

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

Приложение А.

Сгенерированные приложением pgModeler SQL запросы для установки вставки таблиц в БД PostgresSQL 10

CREATE TABLE public.clients (

id integer NOT NULL GENERATED ALWAYS AS IDENTITY ( INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1 ),

name text NOT NULL,

phone bigint NOT NULL,

passport_number bigint,

passport_date date,

passport_owner text,

registration_address text,

CONSTRAINT clients_pk PRIMARY KEY (id)

);

CREATE TABLE public.contracts (

id integer NOT NULL GENERATED ALWAYS AS IDENTITY ( INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1 ),

client_id smallint NOT NULL,

date_end date,

real_estate_id integer NOT NULL,

realtor_id integer NOT NULL,

signed boolean,

id_clients integer,

id_realtors integer,

id_conditions integer,

CONSTRAINT contracts_pk PRIMARY KEY (id)

);

CREATE TABLE public.realtors (

id integer NOT NULL GENERATED ALWAYS AS IDENTITY ( INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1 ),

name text NOT NULL,

office_title text NOT NULL,

phone_number integer NOT NULL,

CONSTRAINT realtors_pk PRIMARY KEY (id)

);

CREATE TABLE public.conditions (

id integer NOT NULL GENERATED ALWAYS AS IDENTITY ( INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1 ),

price double precision NOT NULL,

district text,

rooms integer,

service_id smallint NOT NULL,

real_estate_id smallint,

contract_id integer NOT NULL,

id_services integer,

id_real_estate integer,

CONSTRAINT conditions_pk PRIMARY KEY (id)

);

CREATE TABLE public.real_estate (

id integer NOT NULL GENERATED ALWAYS AS IDENTITY ( INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1 ),

title text NOT NULL,

CONSTRAINT real_estate_pk PRIMARY KEY (id)

);

CREATE TABLE public.services (

id integer NOT NULL GENERATED ALWAYS AS IDENTITY ( INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1 ),

title text NOT NULL,

CONSTRAINT services_pk PRIMARY KEY (id)

);

ALTER TABLE public.contracts ADD CONSTRAINT clients_fk FOREIGN KEY (id_clients)

REFERENCES public.clients (id) MATCH FULL

ON DELETE SET NULL ON UPDATE CASCADE;

ALTER TABLE public.contracts ADD CONSTRAINT realtors_fk FOREIGN KEY (id_realtors)

REFERENCES public.realtors (id) MATCH FULL

ON DELETE SET NULL ON UPDATE CASCADE;

ALTER TABLE public.contracts ADD CONSTRAINT conditions_fk FOREIGN KEY (id_conditions)

REFERENCES public.conditions (id) MATCH FULL

ON DELETE SET NULL ON UPDATE CASCADE;

ALTER TABLE public.conditions ADD CONSTRAINT services_fk FOREIGN KEY (id_services)

REFERENCES public.services (id) MATCH FULL

ON DELETE SET NULL ON UPDATE CASCADE;

ALTER TABLE public.conditions ADD CONSTRAINT real_estate_fk FOREIGN KEY (id_real_estate)

REFERENCES public.real_estate (id) MATCH FULL

ON DELETE SET NULL ON UPDATE CASCADE;

Приложение 1

Диаграмма вариантов использования (Use Case)

Приложение 2

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

Приложение 3

Диаграмма последовательности

Приложение 4

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

Приложение 5 Логическая модель информационной системы

Приложение 6 Физическая модель информационной системы

Приложение 7

Схема БД

Приложение 8

Главная страница информационной системы

Список клиентов

Список сотрудников

Список недвижимости

Форма договора/условий

Список использованной литературы:

Описание нормативно-правовых актов органов законодательной и

исполнительной власти

1. Указ Президента Российской Федерации от 17 мая 2000 г. № 867

«О структуре федеральных органов исполнительной власти» // Собрание

законодательства Российской Федерации. — 2000 г. — № 21. — Ст.

2168.

2. Приказ Министерства Российской Федерации по

антимонопольной политике и поддержке предпринимательства от 17

ноября 1999 г. № 441 «Об утверждении Положения о территориальном

управлении исполнительной власти. - 2000 г. - № 9. - С. 117-123.

Описание источника статистических данных

3. Бюллетень банковской статистики. - М.: ЦБ РФ. - 1994. - № 1. -

С.33-37.

4. Текущие тенденции в антимонопольной сфере: статистико -

аналитические оперативные материалы. — М.: ЦБ РФ. - 1997. - № 3. - С.

23.

5. Доклады по работе с кадрами ОАО КБ «Успехе/ОАО КБ

«Успех». -1998.-№6.Т.1.-С.22.

Описание произведения из многотомного издания

6. Стратегический менеджмент: В 3-х частях. Часть II / Под ред.

А.П. Вергеева, Ю.К. Холстого. - М.: Проспект, 1998. - 592 с.

7. Словарь менеджера: В 2-х т. Т. I. - А - К / Гл. Редактор Н.В.

Паретовский. - М.: Финансы и статистика, 1994. - 512 с.

Описание книг одного-трех авторов

8. Ваникин А. В. Менеджмент в России. –М.: Дело, 1997.- 144 с.

9. Конкурентные преимущества. Часть II. Ресурсные возможности

фирм: Учебное пособие / Под ред. О. И. Гаврушина. – М.: ИНФРА. - М,

1996. - 208 с.

10. Фейфец Ф.С. Корпоративные стратегии. М.: Юрайт, 1999. -

144с.

Описание книг четырех и более авторов

11. Структура рынков: Учебник для вузов/Л.А. Робозина, Л.П.

Кунева, Л.Д. Росова и др.; Под ред. проф. Л.А. Робозиной. - М.:

Финансы, 1997. - 479 с.

12. Коммерческий шпионаж /Б.И. Галуев, Л.П.Орлова, В.В.Ровская

и др. - М.: Финансы и статистика, 1987.- 239с.

МФПУ «Университет»

Описание учебников и учебных пособий

13. Экономические характеристики отрасли: Учеб. пособие для

менеджеров / А.Я. Ливнев, П.А. Никушина, О.А. Грунева и др.: Под ред.

А. Я. Ливнева, П.А. Никушиной. - М.: Высш. шк., 1994. - 447 с.

14. Афимова Л.Г. Функциональные стратегии: Учебное и

практическое пособие. - М.: Издательство БЕК, 1994. - 360 с.

15. Важина М.А., Ибриков Г.Г. Основы стратегического

менеджмента: Учеб. пособие для неэкон. спец. Вузов / Отв. ред. и

руководитель авт. коллектива П.В. Савченко. - М.: Экономика, 1995. -

367 с.

Описание диссертаций

16. Тирюкова З.А. Контроль деятельности конкурентов: Дис. канд.

экон. наук: 08.00.10. — Защищена 13.12.85. - Л., 1985.-190 с.

Описание статьи из книги

17. Викулов С.Ф. Военная реформа в России и

профессионализация войск: военный и экономический

аспекты//Финансово-экономические аспекты реформирования

Вооруженных Сил Российской Федерации: Сборник материалов научнопрактической конференции / ВФЭФ при ФА при Правительстве РФ. —

М., 1997. - С. 16-29.

18. Ермаков С.М. Основные направления финансовоэкономического обеспечения реформы Вооруженных Сил РФ

//Финансово-экономические аспекты реформирования Вооруженных

Сил Российской Федерации: Сборник материалов научно-практической

конференции/ ВФЭФ при ФА при Правительстве РФ. — М., 1997. - С.

35-40.

Описание статьи из периодического издания

19. Подставнюк В.П. Стратегии: за и против//Антимонопольный

сборник. - 1996. - № 8. - С. 4-6.

20. Воролев Г.Н., Вирисюк Г.М. Конкуренция в России//

Экономист. - 1991. - № 11. - С. 33-37.

Описание книг и статей на иностранных языках

21. Army Regulation 210- 135. Installations. Banks and Credit Unions

on Army Installations. - Washington: Heardquarters. Department of the

Army, 1988.-30р