Информационное обеспечение деятельности информационного отдела ООО «Недвижимость +"

МИНИСТЕРСТВО ОБРАЗОВАНИЯ  И НАУКИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ  ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ВОСТОЧНО-СИБИРСКИЙ ГОСУДАРСТВЕННЫЙ  УНИВЕРСИТЕТ ТЕХНОЛОГИЙ И УПРАВЛЕНИЯ

КАФЕДРА «МАКРОЭКОНОМИКИ, ЭКОНОМИЧЕСКОЙ  ИНФОРМАТИКИ И СТАТИСТИКИ»

 

 

 

 

Курсовая работа по дисциплине

«Проектирование информационных систем»

Тема: Информационное обеспечение деятельности информационного отдела ООО «Недвижимость +»

 

 

 

 

 

 

 

 

Выполнил: Болотов Б

студент 529 группы

Проверил:  Полухина О.А.

 

 

Улан-Удэ

2013

План  курсового проекта:

 

Оглавление

План курсового  проекта: 2

Введение 3

1. Теоретическая часть 5

1.1. Основные понятия технологии проектирования информационных систем 5

1.2. Методология проектирования ИС 11

1.3. Моделирование бизнес-процессов средствами BPwin 18

2. Аналитическая часть 20

2.1. Анализ предметной области 20

2.2. Модель как есть 21

2.3. Постановка задачи 24

3. Проектная часть 25

3.1. Разработка модели как должно быть 25

3.2. Описание проектируемых работ 27

3.3. Разработка модели БД 28

Заключение 30

Список источников 31

 

 

 

 

Введение

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

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

В качестве анализируемого предприятия будет рассматриваться  ООО «Недвижимость +», занимающееся оказанием услуг в области недвижимости. Компания «Недвижимость +» основана в 2004 году и на сегодняшний день является одним из лидеров в области разработки, системной интеграции и сопровождения программного обеспечения на территории республики Бурятия. Входит в TOP-3 рейтинга крупнейших IT-компаний региона. Бизнес-партнер ведущих мировых и российских фирм-разработчиков программных продуктов (1С, Microsoft, Лаборатория Касперского, ESET и др.)

 

 

 

 

Целью данного курсовой работы является исследование бизнес-процессов ООО «Недвижимость +», связанных с процессом оказания услуг, возможно с их последующим реинжинирингом, а также создание проекта информационной системы класса CRM

Для достижения цели поставлены следующие задачи:

1. Теоретическое исследование процесса проектирования информационной системы.
2. Анализ текущего состояния информационного обеспечения.
3. Разработка модели информационной системы.

Объект исследования: информационных отдел ООО «Недвижимость +»

Предмет исследования: информационное обеспечение деятельности риэлтора.

 

1. Теоретическая часть

1.1. Основные понятия технологии проектирования информационных систем

Информация - по законодательству РФ - сведения о лицах, предметах, фактах, событиях, явлениях и процессах независимо от формы их представления. Экономическая  информация — информация о процессах  производства, распределения, обмена и  потребления, материальных благ, происходящих на макроэкономическом и микроэкономическом уровнях. Различают прогнозно-аналитическую, плановую, отчетно-статистическую, производственно-технологическую, коммерческую, финансовую, социальную, научную, управленческую информацию.

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

Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу  века приобрела вполне законченные  формы.

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

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

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

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

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

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

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

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

• гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта;

• поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

• обеспечивать преемственность разработки, т.е. использование в разрабатываемой ИС существующей информационной инфраструктуры организации (задела в области информационных технологий).

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

Проектирование ИС охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;

• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Проектирование информационных систем всегда начинается с определения  цели проекта.

Согласно современной  методологии, процесс создания ИС представляет собой процесс построения и последовательного  преобразования ряда согласованных  моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются  специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются  рабочими группами команды проекта, сохраняются и накапливаются  в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.

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

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

Начальным этапом процесса создания ИС является моделирование  бизнес-процессов, протекающих в  организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов  и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное  положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество  моделей описания требований к ИС затем преобразуется в систему  моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры  ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура  ПО и ИО, выделяются корпоративные  БД и отдельные приложения, формируются  модели требований к приложениям  и проводится их разработка, тестирование и интеграция.

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

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

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

Этап проектирования завершается  разработкой технического проекта  ИС.

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

Этап тестирования обычно оказывается распределенным во времени.

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

• обнаружение отказов модуля (жестких сбоев);

• соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

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

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

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

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

Необходимость контролировать процесс создания ИС, гарантировать  достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов  и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.

 

1.2. Методология проектирования ИС

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

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

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

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

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

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

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

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

Методологию IDEF0 можно считать  следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (рис. 6.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

• верхняя сторона имеет значение "Управление" (Control);
• левая сторона имеет значение "Вход" (Input);
• правая сторона имеет значение "Выход" (Output);
• нижняя сторона имеет значение "Механизм" (Mechanism).

 
Рис. 1.1.  Функциональный блок

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

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

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

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

Обязательное наличие  управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие егофункции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

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

В пояснительном тексте к  контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения(Viewpoint).

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

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

Выделение подпроцессов. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели.

Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот —  отдельные дуги нижнего отражать на диаграммах более высоких уровней  – это будет только перегружать  диаграммы и делать их сложными для  восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено  понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, – в таком случае они сначала "погружаются в туннель", а затем при необходимости "возвращаются из туннеля".

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

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

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

• Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы:

Что поступает в подразделение "на входе"?

• Какие функции и в какой последовательности выполняются в рамках подразделения?
• Кто является ответственным за выполнение каждой из функций?
• Чем руководствуется исполнитель при выполнении каждой из функций?
• Что является результатом работы подразделения (на выходе)?

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

• Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 — читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
• Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.