Моделирование основных бизнес-процессов предприятия АНХК

Институт Государственного Управления Права и Инновационных Технологий.

 

 

 

 

 

Курсовая работа

 

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

на тему: «Моделирование основных бизнес-процессов предприятия АНХК»

 

 

 

 

 

 

 

 

 

Выполнил студент V курса

 

 

 

 

 

 

2012 г.

 

Содержание

 

Содержание

Введение

1. Формирование требований как основной этап в разработке АИС

1.1 Техническое задание ---------------------------

1.2 Функциональное моделирование бизнес-процессов

1.3 Среда бизнес моделирования BPwin

2. Проектирование бизнес процесса АНХК -------------

2.1 Описание входной информации

2.2 Описание выходной информации

2.3 Информационный анализ процессов и создание контекстной

диаграммы

2.4 Создание диарграмм моделирования бизнес процесса АНХК-------

Заключение ----------

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

 

Введение

 

Объектом исследования для построения бизнес модели является предприятие АНХК (Ангарская нефтехимическая компания). Химическая промышленность в большей степени, чем любая другая основная отрасль индустрии, характеризуется многообразием используемых технологических процессов.

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

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

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

 

 

1. Формирование требований как основной этап в разработке АИС

 

«Требование – это условие или возможность, которой должна соответствовать система»¹.

В IEEE Standard Glossary of Software Engineering Terminology (1990) [2.1] данное понятие трактуется шире. Требование – это:

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

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

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

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

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

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

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

1. Разработчик представляет Заказчику согласованный план работ c детализацией (WorkBreakdownStructure – WBS) с точностью до конкретных исполнителей.
2. Разработчик осуществляет ежедневные сборки, регрессионное тестирование компонент разрабатываемого продукта и тестирование продукта в целом.
3. Все управленческие и проектные артефакты, исходные коды и тестовые примеры размещаются в режиме online в интегрированной среде разработки Rational ClearCase с возможностью для Заказчика осуществления online-мониторинга на базе web-технологий.

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

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

Обычно выделяют три  уровня требований.

• На верхнем уровне представлены так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.
• Следующий уровень – уровень требований пользователей (user requirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований.
• Третий уровень – функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.

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

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

Внедрение АИС на предприятии приводит к необходимости оснащения всех точек ввода информации автоматизированными рабочими местами (АРМ), обучению персонала и, зачастую, оптимизации и повышению уровня формализации рабочих процессов, выполняемых персоналом. Поэтому внедрение АИС – непростой процесс, часто требующий «перекройки человеческого материала» и встречающий сопротивление со стороны пользователей, которые не готовы, либо не хотят работать по-новому.

Анализ требований – один из основных рабочих потоков (workflow) программной инженерии, наряду с проектирование интерфейса пользователя, либо программированием.

Для его обозначения  в англоязычной литературе, как правило, используется понятие «Requirement Process». В отечественной практике, наряду с обобщающим термином «анализ требований», принятым, в частности, в ГОСТ Р ИСО/МЭК 12207–99, встречаются также такие термины, как «поток работ «требования», «работа с требованиями», «определение требований» и т.д., что вносит изрядную путаницу. Для того чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK, и введем терминологию, которой будет применяться в дипломной работе.

SWEBOK предлагает выделить  в Requirement Process следующие основные  составляющие:

• Requirements Elicitation (Извлечение требований),
• Requirements Analysis (Анализ требований в узком смысле),
• Requirements Specification (Специфицирование требований),
• Requirements Validation (Проверка требований).

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

• Analyze the Problem (Анализ проблемы),
• Understand Stakeholder Needs (Понимание потребностей совладельцев),
• Define the System (Определение системы),
• Manage the Scope of the System (Управление контекстом системы),
• Refine the System Definition (Уточнение определения системы).

Обобщая приведенные  методики, далее будем придерживаться следующей, более удобной в методическом плане схемы декомпозиции потока работ «Работа с требованиями»:

• Формирование видения;
• Выявление требований;
• Классификация и спецификация требований;
• Расширенный анализ требований (моделирование и прототипирование);
• Документирование требований;
• Проверка требований;
• Управление требованиями;
• Совершенствование процесса работы с требованиями.

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

Найти ответ на первый вопрос может помочь общая классификация  задач, работ и операций программной  инженерии, представленная в ГОСТ Р ИСО/МЭК 12207–99. Другая, более поздняя по времени классификация, присутствует в SWEBOK. Однако нужно отметить, что данные руководящие документы рассматривают общий случай, а в частном проекте может быть задействован далеко не весь арсенал работ.

Сложнее – с решением второго вопроса. На сегодня существуют и имеют примеры успешного применения десятки и сотни различных методологий (процессов), среди наиболее известных – MSF, RUP, Oracle PJM, XP, FDD, SCRUM, PSP, Crystal, DSDM. Методологии подразделяются на 3 «волны»: каскадные (исторически первые), прогнозирующие (например, RUP) и «быстрые» (agile), вошедшие в широкую практику на рубеже тысячелетий [4.3].

Описания методологий существенно разняться объемом (от десятков до тысяч страниц текста), наборами базовых работ и рабочих квалификаций, акцентами (работа с моделями, управление рисками, построение команды и пр.). Но авторы их описаний обычно сходятся в одном: лучшая из методологий, которой нужно следовать, чтобы добиться успеха – именно та, которую предлагает (описывает, рекламирует) автор. Редким исключением являются работы А. Коберна, автора группы методологий Crystal, где он предлагает брать за основу не «самый лучший» из процессов, а тот, который, во-первых, наилучшим образом соответствует проектной задаче, а во вторых – команде, которая будет его реализовывать. В [24.3] вводится несколько метрик, позволяющих частично формализовать процесс подбора методологии.