 |
Формирование требований как основной этап в разработке АИС
|
|
|
|
ДИПЛОМНАЯ РАБОТА
«Моделирование основных бизнес-процессов предприятия»
Иркутск 2009
Содержание
Содержание. 2
Введение. 3
1. Теоретическая часть. 9
1.1 Формирование требований как основной этап в разработке АИС.. 9
1.2 Функциональное моделирование бизнес-процессов. 17
1.3 Среда бизнес моделирования BPwin. 35
2. Практическая часть. 41
2.1 Анализ деятельности ОАО «АНХК» и структуры предприятия. 41
2.1 Анализ проблемы автоматизированных информационных систем ОАО «АНХК» 46
2.2 Изучение задач управления. 52
2.3 Описание входной информации. 53
2.5 Описание выходной информации. 54
3. Алгоритм функционирования системы моделирования и его описание. 56
3.1 Информационный анализ процессов и создание контекстной
диаграммы.. 56
3.2 Создание диаграмм декомпозиций. 60
3.3 Создание диаграммы дерева узлов и диаграммы FEO.. 67
Список литературы.. 74
Введение
Целью дипломной работы является изучение проблемы совершенствования информационного обеспечения управления организацией, построение модели основных бизнес процессов на предприятии. На примере конкретного предприятия необходимо выполнить построение моделей бизнес процессов, рассмотреть существующее положение дел в изучаемой области, произвести детальный анализ.
Объектом исследования для построения бизнес модели является предприятие АНХК. Химическая промышленность в большей степени, чем любая другая основная отрасль индустрии, характеризуется многообразием используемых технологических процессов. В химическом производстве задействованы тысячи технологических установок, выпускающих продукцию, причем принципиально одинаковые химические процессы зачастую бывают по-разному оформлены конструктивно, вследствие чего типовые решения могут быть применены лишь для небольшой части общего числа технологических установок.
|
|
|
Поскольку технологические установки составляют основу химических производств, можно представить, какое разнообразие даст сочетание уникальных установок. Как следствие – сложность проблемы управления технологией не уменьшается по мере интеграции производственных подразделений, хотя появляется возможность типизации решений, касающихся управления крупными технологическими комплексами, на основе общности экономических факторов химических предприятий [4].
Такое положение дел во многом обусловило путь, по которому проводилась автоматизация различных иерархических уровней управления, проектировались и развивались автоматизированные системы на предприятиях нефтехимической отрасли. Наибольшее применение получили автоматизированные системы управления технологическими процессами (АСУ ТП) [5–8] и системы автоматизации управленческой и финансово-хозяйственной деятельностью (АСУП) [9]. Гораздо более скромное распространение получили автоматизированные системы оперативного управления [4,10,11] как производством в целом, так и отдельными цехами (так называемые системы верхнего уровня АСУ ТП или автоматизированные системы оперативно-диспетчерского управления – АСОДУ) [12].
Системы АСУ ТП и АСУП – развивались обособленно и независимо друг от друга [13–14]. Они проектировались и создавались исходя из требований разных подразделений предприятия и в соответствии с различными потребностями. Изначально они не были подчинены единым целям и задачам, оставались слабо связанными физически и информационно, а зачастую и не связанными вообще.
Кроме того, каждая из этих систем чаще всего строилась по своим внутренним законам, поэтому они оставались практически изолированными друг от друга информационно. Ситуация осложнялась еще и тем, что каждая из систем могла быть реализована разными коллективами разработчиков на основе различных аппаратных, программных и информационных стандартов.
|
|
|
Рассматривая системы управления технологическими процессами, следует отметить, что не все решения были полностью открытыми [15], т.е. допускающими использование в рамках одной системы разнотипного оборудования, выпущенного в разное время и разными производителями (отечественными и зарубежными). В результате предприятие-заказчик зачастую попадал в долгосрочную зависимость от одного из производителей и не имел возможности самостоятельно развивать и модернизировать АСУ ТП. Если же автоматизированная система разрабатывалась «своими силами», за счет внутризаводских отделов АСУ, то модернизация оборудования практически всегда приводила к разработке системы заново, «с нуля».
Существовали и проблемы «нетехнического характера». Например, автоматизированное решение задач оптимального календарного планирования в рамках АСУП практически не выполнялось [9]. Одной из причин этого являлась меньшая заинтересованность самих предприятий в автоматизированном решении задач планирования. Если на уровне управления установками руководство предприятия, производства, цеха было и заинтересовано в эффективной работе отдельных элементов производства, то на уровне планирования работы предприятия, существующие в то время административные методы управления со стороны министерств, зачастую вступали в противоречия с интересами предприятия. Это не позволяло предприятию принимать эффективные для него автоматизированные решения, а иногда и заинтересовывало его в принятии планов заведомо неоптимального характера.
В итоге это приводило к тому, что создававшиеся без комплексного плана, обычно под требования различных подразделений, участков и процессов, не связанные между собой системы автоматизации с многообразием используемых программных и аппаратных средств очень напоминали «лоскутное одеяло» [16] (впоследствии такой путь получил сленговое название «лоскутной автоматизации»). Понятно, что реальная эффективность от внедрения такой автоматизации на предприятии зачастую получалась весьма низкой.
|
|
|
Переломный момент в сложившейся ситуации произошел после экономических реформ 90-х годов, перераспределения собственности и перехода к рыночным отношениям.
Переход предприятий в «частную собственность» перераспределил и существенно расширил круг задач, требующих решения на химических и нефтехимических производствах. «Когда на предприятии появился хозяин, возникла потребность в получении объективных данных, характеризующих состояние производства и определяющих конечный результат его деятельности. Такими данными является информация о реальном ходе технологических процессов, расходе материалов и, сырья, выпуске готовой продукции и многих других факторах» [17, 18]. К тому же, помимо традиционных задач контроля и управления, появилась необходимость в решении задач минимизации технологических потерь, ужесточении контроля качества выпускаемой продукции, стратегического планирования, логистики, и ряда других.
Свою лепту в изменение ситуации внесло образование вертикально-интегрированных нефтяных компаний (ВИНК). Термин «вертикально-интегрированные» означает, что эти компании охватывают всю цепочку нефтяного бизнеса: разведку и добычу нефти, нефтепереработку и нефтехимию, оптовый и розничный сбыты продукции (рис. 1).
Рис. 1. Схема вертикально-интегрированных нефтяных компаний
Современные мировые транснациональные ВИНК представляют собой гигантские, географически распределенные по всей планете многофункциональные производственно-коммерческие системы. В отличие от них, для российских ВИНК характерно расположение основных добывающих, перерабатывающих и сбытовых мощностей на пространстве бывшего СССР. Поэтому они в большей степени являются едиными операторами всех своих сырьевых, продуктовых и финансовых потоков.
Задача управления текущей деятельностью для российских ВИНК в основном сосредоточена на размещении собственных добываемых сырьевых ресурсов по определенным направлениям [19]. А это, в свою очередь, ставит ВИНК в зависимость от того, насколько полной, достоверной и оперативной будет информация о состоянии производства, выработки, запасах продукции, её качестве от собственных нефтеперерабатывающих заводов и нефтехимических производств.
|
|
|
Таким образом, возникла необходимость в интеграции существующих на предприятиях разрозненных автоматизированных систем для возможности эффективного межуровневого системного взаимодействия и получения единого информационного пространства предприятия. Интегрирование информации основного технологического и вспомогательного производств позволяет объединить разнородные подсистемы в единую систему мониторинга и диспетчеризации технологических и производственных процессов, что повышает эффективность оперативного контроля и управления производством в целом и, как следствие, предприятием
Значимым фактором успеха в деятельности предприятия является применение информационных технологий, автоматизации процесса работы, обеспечивающие согласованное и четкое функционирование всех служб предприятия.
Применение информационных технологий позволяет не проиграть в условиях жесткой конкуренции, обеспечивая своевременные и регулярные поставки, низкую стоимость дополнительных услуг. Для разработки модели основных бизнес процессов на предприятии, рассматривается завод НПЗ.
В дипломной работе проводятся исследования в области проектирования и моделирования АИС. Областью исследования являются новейшие технологии, позволяющие выполнить моделирование бизнес – процессов. Данные технологии предполагают владение инструментами создания графических изображений, методов и средств функционального, логического и физического моделирования. Для реализации поставленных целей необходимо провести анализ работы предприятия.
В рамках дипломной работы поставлены следующие задачи:
1. анализ работы предприятия
2. теоретическое исследование состояния конкретной проблемы – разработка бизнес модели;
3. творческий анализ состояния предприятия и предмета исследования за определенный период, определение и изучение факторов, влияющих на объект и предмет исследования;
4. применение полученных за время обучения навыков владения современными технологиями и методиками решения практических задач или вопросов, поставленных в дипломной работе;
5. разработка методологических подходов, предложений и указаний по планированию, организации и совершенствованию;
6. обобщение полученных в результате проведенных исследований материалов и формулирование аргументированных выводов и рекомендаций.
|
|
|
7. изучить документооборот и информационные потоки, реализующие бизнес-процессы;
8. сформировать модель данных, реализующую выделенный бизнес-процесс;
9. анализ современного состояния развития технологий разработки бизнес моделей и промышленных технологий проектирования ПО.
Тема дипломной работы «Построение модели основных бизнес процессов на предприятии», является, несомненно, актуальной, так как задача такого типа решается на любом предприятии. База данных позволит вести учет поставок, сбыта, выдавать информацию о наличии сырья, обрабатывать большие объёмы информации, формировать необходимые отчеты и запросы. Использование бизнес моделей, обеспечит быструю и эффективную разработку автоматизированной информационной системы, создаст условия для ее хранения и передачи как внутри предприятия, так и по сети Интернет для работы с поставщиками.
Теоретическая часть
Формирование требований как основной этап в разработке АИС
«Требование – это условие или возможность, которой должна соответствовать система»[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] вводится несколько метрик, позволяющих частично формализовать процесс подбора методологии.
Не все работы и операции, известные в программной инженерии, используются в той или иной методологии и, тем более, конкретном проекте. рабочий поток АТ является несомненно необходимым в цепочке рабочих потоков создания информационной системы и на него несомненно стоит тратить время. Проанализировав требуемый объем результатов от АТ можно утверждать что как этап разработки ИС, невозможно пропустить АТ, этот этап закладывает фундамент всего процесса проектирования и реализации системы. Уровень проработки АТ может быть различным: от совершенно неформальной записки, представленной на одной странице, до развернутой системы документов, моделей и прототипов, построенной в соответствии с принципами одной из прогнозирующих методологий, например, RUP. Это зависит от следующих основных факторов: размеров проекта, величины имеющихся ресурсов и степени рисков. Невысокая глубина проработки приемлема для небольших проектов, характеризующихся небольшим ресурсом и невысокими рисками. Хорошо проработанные требования позволяют:
· выработать общее понимание между Заказчиком и Разработчиком;
· определить рамки проекта;
· более точно определить финансовые и временные характеристики проекта;
· обезопасить Заказчика от риска получить продукт, в котором он не сможет работать,
· обезопасить Разработчика от риска попасть в ситуацию «неконтролируемого размытия границ», которое может привести к непредвиденным затратам ресурсов сверх начальных ожиданий.
Анализ требований – это процесс (бизнес-процесс) и, следовательно, к нему подходят методы и средства процессного подхода к управлению[2].
Один из ключевых вопросов, позволяющих оценить результативность процесса – что является выходом (результатом) процесса. В чем результат АТ? Результатом рабочего потока «анализ требований» является набор артефактов. Это могут быть текстовые документы, модели UML, либо других языков моделирования, прототипы программного обеспечения.
Проанализируем другой важный вопрос – какие цели преследует процесс. RUP предлагает следующие цели для потока работ АТ:
· добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система;
· дать разработчикам наилучшее понимание требований к системе;
· определить границы системы;
· определить интерфейс пользователя и системы.
Выдвинутые цели отражены в рис. 2
Рис. 2. Контекст технологической операции проектирования
Выводы: результаты анализа требований во многом определяют успех проекта, требования являются необходимой составляющей в разработке проекта, от правильно сформулированных и разработанных требований, зависит успех проекта, но какова роль бизнес-анализа и бизнес-моделирования предстоит исследовать и проанализировать. Стоит разобраться, в каком случае следует применять анализ требований, бизнес-анализ или бизнес-моделирование.
|
|
|
