Формирование проекта финансирования молодежного ночного клуба

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Федеральное агентство по образованию

Государственное образовательное учреждение

высшего профессионального образования

«ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ УПРАВЛЕНИЯ»

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

КУРСОВОЙ ПРОЕКТ

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

на тему: Формирование проекта финансирования молодежного ночного клуба

Выполнила:

Студентка Власова О.Н.

Группа ФМ-4-1

Проверил:

Доцент кафедры

управления финансовыми рисками

к.т.н., доцент Б.В. Черников

Москва, 2007

Оглавление

Введение

1. Описание процесса

2. Функциональная модель SADT

2.1 Технология создания SADT модели

2.1.1 Стоимостной анализ (Activity Based Costing)

2.1.2 Построение отчетов

2.1.3 Построение HTML-отчета

2.1.4 Свойства, определяемые пользователем (User Definition Proprieties)

2.1.5 Использование UDP для экспорта данных в MS Project 2003

2.2 Описание SADT модели

3. Модель потоков данных DFD

3.1 Технология создания DFD модели

3.2 Описание DFD модели

4. UML модель

4.1 Технология создания UML модели

4.1.1 Документирование моделей

4.1.2 Формирование HTML-отчета

4.2 Описание UML модели

5. План выполнения проекта

5.1 Технология создания плана работ по проекту

5.2 Описание плана выполнения работ по проекту

Заключение

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

Приложения

Отчет по стоимостному анализу

DFD-модель

UML-модель

План работ по проекту

Введение

модель данный стоимостной диаграмма

Данный курсовой проект направлен на изучение и освоение компьютерных средств моделирования бизнес-процессов. При этом используются CASE-технологии, нашедшие свое проявление в различных компьютерных программах и пакетах: BPWin, Case. Главные достоинства CASE-технологий - это ускорение и автоматизация анализа бизнес-процессов.

Курсовой проект направлен в основном на получение знаний в области применения CASE-технологий в разных компьютерных средах. Для представления разных типов моделей (SADT, DFD, UML, MS Project), используются различные программы. Курсовой проект устроен таким образом, что каждая задача рассматривается подробно: для каждой модели рассматривается общая теория, процесс создания, конечный результат.

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

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

2. Описание процесса

Основные этапы формирования проекта финансирования молодежного ночного клуба.

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

Формирование сметы проекта.

Формирование плана инвестирования.

Реализация проекта.

Формирование сметы проекта.

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

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

Формирование проекта инвестирования.

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

Реализация проекта.

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

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

Далее в проекте будут рассмотрены более подробно все этапы формирования проекта финансирования молодежного ночного клуба.

Функциональная модель SADT.

2.1 Технология создания SADT модели

Функциональная модель SADT, в нотации IDEF0 (Business Process), представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Это - контекстная диаграмма, диаграммы декомпозиции, диаграмма древа узлов и диаграмма для экспозиции.

SADT, служит для построения функциональной модели объекта какой-либо области.

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

Рис. 1

Тогда будет справедливо следующее высказывание: М модель системы S, если может быть использована для получения ответов на вопросы относительно S, с точностью A.

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

Таблица 1

Тип стрелки	Сущность стрелки	Положение
Вход	Информация, которая преобразуется	Слева
Управление	Правила, которыми руководствуется работа	Сверху
Механизмы	Кто выполняет работу	Снизу
Выход	Произведенная информация, материал	Справа
Вызов	Специальный указатель на другие работы	-

Схематично, это выглядит так:

Рис. 2

В модели SADT, существуют различные типы связей. Их можно разделить по значимости на 7 уровней:

«Случайная связь» - связь представляет собой наименее важное значение.

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

«Временная связь» - функции связаны во времени. Данные используются одновременно или функции включаются параллельно.

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

«Коммуникационная связь» - функции группируются вместе, т.к. используют одни и те же входные или порождают одни и те же выходные данные.

«Последовательная связь» - обозначение причинно-следственной зависимости.

«Функциональная связь» - все элементы функции влияют на выполнение 1-ой функции.

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

Разработка и построение заданного бизнес-процесса в среде BPwin начинается с запуска программы из главного меню: Пуск - Все программы - All Fusion Process Modeler.

При создании новой модели необходимо в открывшемся диалоговом окне задать следующие параметры (Рис. 3)

Рис. 3Выбор нотации моделирования

Дать имя модели

Выбрать методологию построения

Bpwin поддерживает три методологии моделирования:

Функциональное моделирование (IDEF0);

Описание бизнес-процессов (IDEF3);

Диаграммы потоков данных (DFD).

Подтверждение введенных данных осуществляется нажатием функциональной клавиши «OK».

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



Рис. 4 Диалог задания автора

Подтверждение введенных данных осуществляется нажатием функциональной клавиши «OK».

Поле работы в нотации IDEF0 представлено на (Рис. 5):

Рис. 5 Поле работы

После создания модели нужно задать свойства модели. Это можно сделать двумя способами:

Раздел главного меню Model - Model Properties;

на свободном поле вызвать контекстно-зависимое меню - Model Properties.

Во вкладке General (Рис. 6) в поле Model name указано имя модели. В поле Project записано условное имя проекта. В поле Author указано имя автора проекта. В группе Time Frame расположены две кнопки для построения модели либо в варианте AS-IS («как есть»), либо в варианте TO-BE («как будет»). Установленный флажок «AS-IS» свидетельствует о том, что заданы временные рамки описываемого процесса.

Рис. 6 Диалог задания свойств модели (Вкладка General)

Во вкладке Purpose (Рис. 7) указывается Цель разрабатываемой модели (Purpose) и точка зрения (Viewpoint).



Рис. 7 Диалог задания свойств модели (Вкладка Purpose)

Подтверждение введенных свойств осуществляется нажатием функциональной клавиши «OK».

Для того чтобы внести имя работы нужно вызвать контекстно-зависимое меню и выбрать команду Name (Рис. 8).

Рис. 8 Наименование работы

Но прежде чем вносить имя работы нужно настроить шрифт во вкладке Font (Рис. 9). Обязательным является установка флажка «Change all occurrences», что позволит применить выбранные параметры шрифта для всей модели.



Рис. 9 Выбор шрифта

После задания шрифта нужно перейти во вкладку Name (Рис. 10) и задать имя работы.

Рис. 10 Ввод имени работы

Подтверждение заданных параметров осуществляется нажатием «OK». (Рис. 11)



Рис. 11 Контекстная диаграмма

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

Рис. 12 Палитра инструментов ("Режим рисования стрелок")

Далее нужно подвести курсор стрелки к нужной стороне экрана (Рис. 13) в зависимости от назначения стрелки.

Рис. 13 Рисование стрелки 1-й шаг

Затем щелкнуть по полоске и протянуть мышку до нужного сегмента, куда должна входить стрелка (Рис. 14).



Рис. 14 Рисование стрелки 2-ой шаг

Подпись стрелок осуществляется следующим образом, в «Режиме редактирования» (Рис. 15) щелкнуть на линии мыши правой кнопкой мыши, вызвать контекстно-зависимое меню и выбрать Name.

Рис. 15 Палитра инструментов ("Режим редактирования")

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

Чтобы добавить на контекстную диаграмму цель и точку зрения нужно выбрать команду вставки текстового объекта (Рис. 16).

Рис. 16 Панель инструментов ("Режим вставки текстового объекта)

После этого нужно щелкнуть в левый нижний угол - появится окно (Рис. 17), где нужно сначала нужно выбрать цель, а потом точку зрения и подтвердить выбор «OK» (Рис. 18).



Рис. 17 Добавление цели и точки зрения

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

Рис. 18 Родительская диаграмма

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

Рис. 19 Панель инструментов (Переход по уровням декомпозиции)

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

Рис. 20 Диалоговое окно Activity box Count

Автоматически будет создана диаграмма декомпозиции (Рис. 21).

Рис. 21 Диаграмма декомпозиции

Для идентификации граничных стрелок используют коды ICOM (Input, Control, Output, Mechanism). Для автоматического отображения кодов нужно включить опцию «ICOM codes» во вкладке Display Model - Model Properties (Рис. 22).



Рис. 22 Диалог задания свойств модели (Display)

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

Рис. 23 Диаграмма декомпозиции

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

Полученный результат представлен в Приложении 1.

В дополнение к контекстной диаграмме и диаграммам декомпозиции при разработке и представлении моделей применяется диаграмма Дерево узлов. В разделе главного меню Diagram выбрать «Add Note Tree…». После это появляется диалоговое окно (Рис. 24), в котором указывается название диаграммы Дерева узлов, узел верхнего уровня (Контекстная диаграмма), количество уровней, которые нужно показывать (3). При нажатии клавиши «Далее» появляется следующее диалоговое окно (Рис. 25), в котором указываются дополнительные настройки.

Рис. 24 Node Tree Wizard - Step 1 of 2



Рис. 25 Node Wizard - Step 2 of 2

Полученный результат представлен в Приложении 2.

2.1.1 Стоимостной анализ (Activity Based Costing)

Стоимостный анализ представляет собой суммарную оценку затрат на работу всей модели, которая состоит из оценок отдельных функциональных блоков модели. При проведении стоимостного анализа сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model Properties (Model - Model Properties) вкладка ABC Units (Рис. 26).

Рис. 26 Настройка единиц измерения валюты и времени

Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Dictionary (меню Dictionary - Cost Center…) (Рис. 27).

Рис. 27 Диалог Cost Center Dictionary

Для задания стоимости работы (для каждой работы на диаграмме декомпозиции) следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать Costs (Рис. 28).

Рис. 28 Задание стоимости работ в диалоговом окне Activity Properties

Из списка выбирается один из центров затрат и в окне Cost задается его стоимость. Аналогично назначаются суммы по каждому центру затрат, т.е. задается стоимость каждой работы по каждой статье расхода. Если в процессе назначения стоимости возникает необходимость внесения дополнительных центров затрат, диалог Cost Center Editor вызывается прямо из диалога Activity Properties соответствующей кнопкой. Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей работы сначала вычисляется произведение затрат дочерней работы на частоту работы, затем результаты складываются.

2.1.2 Построение отчетов

BPwin предоставляет набор отчетов для публикации информации, которая помещена в модель. Для формирования отчетов необходимо в главном меню Tools выбрать команду Reports. В выпадающем окне представлены следующие отчеты:

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

Рис. 29 Model Report

отчет по диаграммам (Diagram Report) - включает информацию об объектах в активной диаграмме Bpwin (Рис. 30).



Рис. 30 Diagram Report

отчет об объектах диаграммы (Diagram Object Report) (Рис. 31) - содержит информацию об объектах, размещенных на диаграмме. Для выполнения отчета об объектах диаграммы нужно:

определить объекты диаграммы и степень детализации отчета;

выбрать элементы данных, которые нужно включить в отчет;

определить дополнительные параметры форматирования для печати или имена дисковых файлов;

определить, как данные отчета будут упорядочены.

Рис. 31 Диалог задания параметров отчета

2.1.3 Построение HTML-отчета.

Для построения отчета используется генератор отчетов (Рис. 32).

Рис. 32 Report Builder

До вызова генератора отчетов необходимо перейти к контекстной диаграмме. В появившемся окне выбирается новый отчет (Рис. 33).

Рис. 33 Report Templates

Далее открывается окно (Рис. 34), в котором слева располагаются все возможные секции отчета. Для выбора секции следует щелкнуть по стрелке. После щелчка по стрелке справа появляется выбранная секция. Обязательно нужно выбрать секцию Picture.

Рис. 34 Report Templates Builder

Для генерации отчета необходимо щелкнуть по стрелке (Рис. 35).

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

Рис. 36 Активизированная контекстная диаграмма

2.1.4 Свойства, определяемые пользователем (User Definition Proprieties)

Свойство, определяемое пользователем UDP, создается для отображения произвольной информации, относящейся к конкретному функциональному блоку или стрелке. Для описания UDP служит диалог UDP Dictionary (меню Dictionary - UDP) (Рис. 37)

Рис. 37 UDP Dictionary

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

2.1.5 Использование UDP для экспорта данных в MS Project 2003

В стандартном наборе средств Bpwin 4.1 отсутствует возможность экспорта данных функциональной модели в средства управления проектами. Однако эта задача может быть решена с помощью свойств, определяемых пользователем (UDP). Экспорт данных непосредственно из Bpwin в Project невозможен, однако можно перенести данные через промежуточный экспорт в MS Excel.

Для экспорта данных из Bpwin в MS Excel следует сгенерировать отчет по объектам (меню Tools/Reports/Diagram Object Report) (Рис. 38) и экспортировать его MS Excel по протоколу DDE. Кроме значений UDP в отчет включены наименования работ, которые будут использованы в качестве наименования задач в проекте Project, и наименования стрелок механизма, которые будут использоваться как название ресурсов.

Рис. 38 Настройки отчета для экспорта данных в диалоге Diagram Object Report

Для успешного экспорта необходимо предварительно запустить MS Excel, после чего щелкнуть по кнопке Report диалога Diagram Object Report. После завершения экспорта следует сохранить файл и закрыть MS Excel.

2.2 Описание SADT модели

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

Данный процесс можно разбить на три основных функциональных блока:

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

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

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

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

А1.4. Руководствуясь налоговым кодексом, гражданским кодексом, и исходя из информации о доходах и расходах, финансовый отдел составляет предварительную смету проекта.

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

А1.6. Руководствуясь налоговым кодексом и нормами финансовой отчетности, имея скорректированную предварительную смету проекта, финансовый отдел составляет окончательную смету проекта под руководством генерального директора.

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

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

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

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

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

3. Модель потоков данных DFD

3.1 Технология создания DFD модели

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

Разработка и построение заданного бизнес-процесса в среде BPwin начинается с запуска программы из главного меню: Пуск - Все программы - All Fusion Process Modeler.

При создании новой модели необходимо в открывшемся диалоговом окне (Рис. 39) задать следующие параметры:

Рис. 39 Выбор нотации моделирования

Дать имя модели

Выбрать методологию построения

Bpwin поддерживает три методологии моделирования:

Функциональное моделирование (IDEF0);

Описание бизнес-процессов (IDEF3);

Диаграммы потоков данных (DFD).

Подтверждение введенных данных осуществляется нажатием функциональной клавиши «OK».

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

Рис. 40 Диалог задания автора

Подтверждение введенных данных осуществляется нажатием функциональной клавиши «OK».

Поле работы в нотации IDEF0 представлено на Рис. 41:

Рис. 41 Поле работы

После создания модели нужно задать имя модели. Это можно сделать двумя способами:

- Раздел главного меню Model - Model Properties;

- на свободном поле вызвать контекстно-зависимое меню - Model Properties.

Во вкладке General (Рис. 42) в поле Model name указано имя модели. В поле Project записано условное имя проекта. В поле Author указано имя автора проекта. В группе Time Frame расположены две кнопки для построения модели либо в варианте AS-IS («как есть»), либо в варианте TO-BE («как будет»). Установленный флажок «AS-IS» свидетельствует о том, что заданы временные рамки описываемого процесса.

Рис. 42Диалог задания свойств модели (Вкладка General)

Подтверждение введенных свойств осуществляется нажатием функциональной клавиши «OK».

Для того чтобы внести имя работы нужно вызвать контекстно-зависимое меню (Рис. 43) и выбрать команду Name.

Рис. 43 Наименование работы

Но прежде чем вносить имя работы нужно настроить шрифт во вкладке Font (Рис. 44). Обязательным является установка флажка «Change all occurrences», что позволит применить выбранные параметры шрифта для всей модели.

Рис. 44 Выбор шрифта

После задания шрифта нужно перейти во вкладку Name (Рис. 45) и задать имя работы.

Рис. 45 Ввод имени работы

Подтверждение заданных параметров осуществляется нажатием «OK».

Контекстная диаграмма (Рис. 3.1.8) определяет основной процесс информационной системы.

Рис. 46 Контекстная диаграмма

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

Рис. 47 Панель инструментов (Переход по уровням декомпозиции)

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

Рис. 48 Диалоговое окно Activity box Count

Автоматически будет создана диаграмма декомпозиции (Рис. 49).



Рис. 49Диаграмма декомпозиции

На диаграмме декомпозиции, используя панель инструментов (Рис. 50) вносятся необходимые компоненты диаграммы.

Рис. 50 Панель инструментов

Основные компоненты диаграмм потоков данных (Диаграмма Гейна-Сарсона):

Внешние объекты (Рис. 51) - источники или потребители информации, порождающие или принимающие информационные потоки.

Рис. 51 Внешний объект

Процессы (Рис. 52), представляющие преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом.

Рис. 52 Процесс

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

Рис. 53 Накопители данных

Потоки данных (Рис. 54), определяющие информацию, передаваемую через некоторое соединение от источника к приемнику.

Рис. 54 Потоки данных

После внесения всех необходимых компонентов (кроме потоков данных), вносятся стрелки, которые описывают передвижение объектов от одной части системы к другой. Стрелки в DFD-модели могут начинаться и заканчиваться в любой части блока (в отличие от IDEF0). Для этого необходимо щелкнуть по кнопке с символом стрелки («Режим рисования стрелок») в палитре инструментов (Рис. 55).

Рис. 55 Палитра инструментов ("Режим рисования стрелок")

Далее, при направлении курсора мыши на нужный компонент появляется черное поле, необходимо нажать на компонент и протянуть курсор мыши до нужного компонента и нажать правой клавишей мыши при появлении черного поля. Подпись стрелок осуществляется следующим образом, в «Режиме редактирования» (Рис. 56) щелкнуть на линии мыши правой кнопкой мыши, вызвать контекстно-зависимое меню и выбрать Name.

Рис. 56 Палитра инструментов ("Режим редактирования")

В DFD-модели все стрелки должны быть подписаны, не подписанных стрелок в DFD-моделях не бывает. Все стрелки подписываются именами существительными.

Согласно описанной выше технологии декомпозируются следующие элементы.

Полученный результат представлен в приложении 3.

3.2 Описание DFD модели

Диаграммы потоков данных моделируют систему как набор действий, соединенных друг с другом стрелками. В отличие от стрелок в IDEF0, которые иллюстрируют отношения, стрелки в DFD показывают, как объекты (включая и данные) реально перемещаются от одного действия к другому. Работы в моделируемой DFD-диаграмме связаны следующим образом:

А01. На этом этапе на основании приказов генерального директора , с учетом различных законодательных норм, предоставляется информация для формирования сметы проекта.

А1.1. Генеральный директор генерирует идею об открытии молодежного ночного клуба. Для начала финансовый отдел на основании правил бюджетирования формирует статьи бюджета проекта.

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

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

А1.4. Финансовый отдел на основании предоставленной информации о доходах и расходах, а также руководствуясь законами гражданского и налогового кодекса, составляет предварительную смету проекта.

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

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

А02. На основании сметы проекта, с учетом законодательных норм, на основании приказов генерального директора, формируется план инвестирования.

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

А2.2. Инвесторы формируют критерии анализа проекта, совместно с генеральным директором и финансовым отделом, руководствуясь гражданским кодексом, анализируют смету проекта, результатом чего является проанализированная смета проекта.

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

А03. Исходя из плана инвестирования, руководствуясь налоговым кодексом, на основании приказов генерального директора, происходит реализация проекта сотрудниками на деньги, данные для проекта.

4. UML модель

4.1 Технология создания UML модели

Объектно-ориентированные модели строятся на основе языка UML. UML - язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и прочих систем не программного обеспечения.

Разработка и построение заданного бизнес-процесса в среде Enterprise Architect начинается с запуска программы из главного меню: Пуск - Все программы - Enterprise Architect 6.0.

В стартовом окне программы выбрать команду настройки профиля My Profile (Рис. 57).

Рис. 57 My Profile

В данном окне необходимо заполнить поле My name, которое будет указываться как имя автора проекта. Выбрать стандарт UML 2.0.

По щелчку по кнопке Customize Interface можно провести первичную настройку интерфейса. По щелчку по кнопке Show Keyboard Map можно посмотреть комбинации клавиш для определенных команд.

Для инициации создания модели нужно в стартовом окне выбрать команду Create a new Project (Рис. 58). По команде открывается диалоговое окно, в котором в строке New Project необходимо ввести имя проекта и указать место расположения. В строке Model Project указывается стартовый шаблон построения модели.

Рис. 58 Инициация создания новой модели

После подтверждения введенных данных (нажатие клавиши «Create Project») появляется дерево модели (Рис. 59).

Рис. 59 Окно навигатора модели

Формирование модели начинается с построения Ролевой диаграммы, которая отображает функции участников и их взаимосвязи. Для построения ролевой диаграммы удобнее всего использовать два вида диаграмм в классе модели Use Case View: Business Process Model и Use Case Model. Данная UML-модель будет строиться на основе Use Case Model. Для построения ролевой диаграммы необходимо в окне навигатора модели (Рис. 60) открыть группу Use Case Model и дважды щелкнуть по пиктограмме Use Case Model.

Рис. 60 Окно навигатора проекта

После этого появится окно модели (Рис. 61) и ярлык Use Case Model.

Рис. 61 Окно модели

Далее необходимо установить из палитры Use Case (Рис. 62) нужные компоненты, задавая при их установке свойства и имя компонента в автоматически появляющейся панели (Рис. 63). Для редактирования свойств элемента нужно дважды щелкнуть на элементе.



Рис. 62 Палитры создания UML-диаграмм

Рис. 63 Свойства компонента

Далее нужно расставить связи. Для расстановки связей нужно:

выбрать тип связи в палитре

щелкнуть на исходном элементе

при зажатой клавише протащить курсор до целевого элемента

Типы связей (в палитре Use Case):

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

Рис. 64 Связь Generalize

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

Рис. 65 Связь Associate

Realize - реализация (Рис. 66) - исходный объект реализует объект расположения. Связь используется для трассировки модели процесса или требования, реализованных одним или более случаями использования, предназначенными для определенного компонента. Связь исполнения.



Рис. 66 Связь Realize

Dependency - зависимые (Рис. 67) - отношение между двумя элементами моделирования, в котором изменение в одном элементе моделирования, повлияет на другой элемент моделирования.

Рис. 67 Связь Dependency

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

После расстановки связей необходимо ввести описание ролевых функций. Для этого нужно добавить зависимые заметки (Рис. 68). Для этого необходимо вызвать контекстно-зависимое меню на ролевом объекте, выбирается команда ADD, из меню второго уровня выбирается Attach Note.

Рис. 68 Зависимая метка

После выбора команды Attach Note появляется зависимая заметка. Чтобы ввести описание ролевых функций необходимо дважды щелкнуть на заметке и ввести текст в окне Notes. Рекомендованная формулировка ролевых функций должна отвечать на вопрос: «Что делает ролевой объект?». Подтверждение введенного текста осуществляется нажатием клавиши «OK». После ввода текста появляется заметка с веденным текстом (Рис. 68).

Далее строится контекстная диаграмма. Так как в классе Use Case уже построена ролевая диаграмма, то нужно добавить еще одну диаграмму этого класса. Для того чтобы добавить диаграмму необходимо в разделе Project выбрать команду Add Diagram и, в появившемся окне (Рис. 69) выбрать тип диаграммы, и ввести название диаграммы. Подтверждение осуществляется нажатием «OK».

Рис. 69 Добавление новой диаграммы

После добавления контекстной диаграммы необходимо из палитры Use Case установить все объекты, которые были на ролевой диаграмме, задавая при их установке свойства компонента в автоматически проявляющейся панели. В контекстную диаграмму устанавливаем дополнительно элементы из палитры Use Case «Use Case» (Рис. 70).

Рис. 70 Элемент Use Case

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

Добавить нужный вид диаграммы

Для добавления декомпозирующей диаграммы на родительском элементе следует вызвать контекстно-зависимое меню выбрать команду ADD (Рис. 71) и в выпадающем меню выбрать Activity Diagram. Подтверждение осуществляется клавишей «OK».

Рис. 71 Добавление новой диаграммы

Отметить родительский элемент как составной

Для того чтобы отметить родительский элемент как составной следует вызвать контекстно-зависимое меню, выбрать команду Advanced Settings и включить переключатель Composite Element. На элементе после включения переключателя появляется отметка составного элемента (Рис. 72).

Рис. 72 Составной элемент

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

Для наглядности классификации информации рекомендуется настроить так называемые «ролевые полосы» (Swimlanes), каждая из которой будет предназначена для размещения элементов определенного назначения:

Информация

Действия

Роли

Настройка проводится по команде Configure Swimlanes раздела Главного меню Diagrams. По этой команде открывается окно (Рис. 73), в котором настраиваются свойства ролевых полос: положение полос, параметры линий и текста, ввод новой полосы, изменений выбранной полосы, удаление полосы и изменение последовательности полос. Для создания полос нужно щелкнуть по кнопке New и ввести наименование.

Рис. 73 Добавление ролевых полос

В диаграммах Activity используется два вида связей:

- Control Flow - управляющий поток (Рис. 74) - связь между элементами действия в диаграмме.



Рис. 74 Вид связи Control Flow

- Object Flow - поток данных (Рис. 75) - связь между элементами диаграммы при передаче каких-либо данных.

Рис. 75 Вид связи Object Flow

При построении диаграммы декомпозиции в полях информация и действия связи и элементы берутся из палитры Activity, а в поле роли - элементы и связи из палитры Use Case.

В диаграмме Activity всегда есть начало процесса и конец (Рис. 76). Элементы Initial и Final должны подписываться.

Рис. 76 Элементы Initial и Final

Для отображения инициации процесса используется связь Realize из палитры Use Case.

Для построения диаграммы активности используются элемент Activity (Рис. 77) и элемент Decision (Рис. 4.1.24) (элемент условия) из палитры Activity.

Рис. 77 Элемент Activity

Рис. 78 Элемент Decision

При помощи элемента Decision создается ветвление процесса. Для указания элементов в ролевой полосе информация (сведения, данные, документы, оборудование и т.п.) используется элемент Object (Рис. 79).

Рис. 79 Элемент Object

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

Для подписи модели необходимо в Главном меню Diagram выбрать Insert Property Note. После чего в верхнем левом углу появляется поле (Рис. 80), при необходимости поле можно перемещать.

Рис. 80 Подпись модели

Полученный результат представлен в приложении 4.

4.1.1 Документирование моделей

Для формирования твердых копий следует сохранить каждую диаграмму в виде отдельной картинки в отчуждаемом формате. Для этого используется из раздела Главного меню Diagram «Save Image to File». В появившемся окне (Рис. 81) необходимо указать расположение сохраняемых файлов, задать имя файла и выбрать формат .PNG.

Рис. 81 Документирование моделей

Полученный результат представлен в приложении 4.

4.1.2 Формирование HTML-отчета

Создание отчета по проекту может формироваться в виде следующих вариантах:

В виде текстового документа

В виде HTML-страницы (интерактивный отчет)

Отчет только по диаграммам

Для генерации отчета в виде HTML-страницы обязательно нужно перейти к ролевой диаграмме проекта. Выбрать из Главного меню Project команду Documentation, в появившемся окне выбрать HTML Report. В открывшемся окне (Рис. 82) нужно выбрать папку для хранения отчета, включаемые в отчет компоненты и формат изображения. После генерации отчета (Generate) становится активной кнопка View и при нажатии кнопки View можно посмотреть сгенерированный отчет.

Рис. 82 Окно генератора отчета

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

Рис. 83 Активизированная диаграмма декомпозиции

4.2 Описание UML модели

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

Ролевая диаграмма.

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

Бухгалтерия представляет информацию о расходах, информацию о доходах.

Отдел рекламы представляет данные отдела рекламы.

Отдел снабжения представляет данные отдела снабжения.

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

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

Контекстная диаграмма.

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

Диаграмма декомпозиции.

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

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

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

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

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

Диаграмма декомпозиции «Сформировать план инвестирования».

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

5. План выполнения проекта

5.1 Технология создания плана работ по проекту

Существует 2 способа создания диаграммы Ганта с помощью программы Microsoft Project 2003.

1. Функциональная модель, создаваемая с помощью BPwin, не позволяет решать задачи управления проектом. Планирование выполнения данного проекта будет выполнено в стандартном наборе BPwin отсутствует возможность экспорта данных функциональной модели в средства управления проектами. Но это задача может быть решена с помощью свойств UDP, определяемых пользователем. Применяя UDP, можно экспортировать данные из среды BPwin в Project 2003, причем в результате такого экспорта сетевой график создается автоматически. Задание и присвоение значение UDP и промежуточный экспорт данных из BPwin в MS Excel рассмотрен в главе 2.1.

Для импорта из MS Excel необходимо открыть Project 2003 из главного меню: Пуск - Все программы - Microsoft Office - Microsoft Office Project 2003. До начала импорта необходимо установить рабочее время. Для этого необходимо в главном меню Сервис выбрать команду Изменить рабочее время. В появившемся окне (Рис. 84) следует задать для каждого дня свое рабочее время. Подтверждение осуществляется нажатием клавиши «OK».



Рис. 84 Изменение рабочего времени

В окне Project 2003 следует перейти в меню Файл/Открыть. В нижнем раскрывающемся списке Тип Файлов диалога Открытие документа выбрать Книги Microsoft Excel, в верхнем окне предварительно выбрать сохраненный файл MS Excel.

Появляется диалог Мастер импорта (Рис. 85).

Рис. 85 Диалог мастера импорта

При нажатии кнопки Далее появляется следующее диалоговое окно

(Рис. 86).



Рис. 86 Диалоговое окно Мастера импорта - схема

Так как мастер импорта ранее не использовался, и сохраненных схем нет, следует выбрать «Создать новую схему». При нажатии клавиши «Далее», появляется следующее диалоговое окно (Рис. 87).

Рис. 87 Мастер импорта - режим импорта

При импорте данных следует выбрать «Создать новый проект» При нажатии клавиши «Далее», появляется окно (Рис. 88), в котором необходимо выбрать тип импортируемых данных.



Рис. 88 Мастер импорта - параметры схемы

При нажатии клавиши «Далее» появляется окно (Рис. 89), в котором необходимо установить опции соответствия полей MS Excel и Project.

Рис. 89 Мастер импорта - сопоставление задач

При нажатии клавиши «Далее» в появившемся окне можно сохранить настройки мастера для дальнейшего использования и завершить операцию импорта, нажав кнопку «Готово». В Project 2003 автоматически создает проект на основе импортированных данных. Диаграмма Ганта созданного проекта показана в Приложении № 5.

Работы функциональной модели конвертировались в задачи проекта Project 2003, а стрелки механизмов - в ресурсы.

2. Вторым способом является создание нового документа с помощью программы Microsoft Project 2003.

Первым шагом запускаем программу из меню Пуск - Microsoft Office - Microsoft Project 2003.



Рис. 90 Стартовое окно программы

Слева в стартовом окне (Рис. 90) расположен перечень задач. В перечне последовательно выбираются решаемые задачи. При решении конкретной задачи в панели задач отображаются пункты с наименованием этапов, которые нужно пройти. Содержание панели задач изменяется в зависимости от задачи, решаемой в данный момент.

При планировании задач используется иерархическая структура работ. Основные типы задач:

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

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

Обычные задачи, в свою очередь, подразделяются на:

Суммарные задачи - задачи, которые объединяют и суммируют другие задачи, каким-либо образом связанные между собой.

Подзадачи или частные задачи - задачи, объединяемые суммарной задачей и перечисленные под ней.

Прежде чем, заполнять название задач необходимо задать настройки времени. Это производится через команду Сведения о проекте раздела Главного меню Проект (Рис. 91).

Рис. 91 Окно настроек параметров проекта.

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

Но, поскольку в течение выполнения проекта встречаются праздничные дни, необходимо задать дополнительные настройки календаря. Это производится через команду «Изменить рабочее время» из раздела Главного меню Сервис (Рис. 92).

Рис. 92 Изменение рабочего времени

Здесь задаются нестандартные выходные и рабочие дни, нестандартное рабочее время и т.д.

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