|
аждая из работ на диаграмме декомпозиции может быть, в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована.Рис. 24 Пример диаграммы декомпозиции Производство продукцииВзаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными В IDEFO различают пять типов стрелок:Вход (Input) - материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов.Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. «Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой. Если цель работы изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т.д. Стрелка механизма рисуется как входящая в нижнюю грань работы.Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, и наоборот. Такие стрелки называются граничными.ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы (рис. 25). В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что и работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что и границы диаграммы декомпозиции.Рис. 25. Фрагмент диаграммы декомпозиции ICOM-кодам (11, С1 и С2)BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на вкладке Display диалога Model Properties (меню Model/Model Properties).Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary, в котором определяется стрелка и вносится относящийся к ней комментарий. Рис. 26 Словарь стрелокСловарь стрелок решает очень важную задачу. Содержимое словаря стрелок можно распечатать в виде отчета (меню Tools/Reports/Arrow Report) и получить тем самым толковый словарь терминов предметной области, использующихся в модели.Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т.е. обсудить Диаграмму со специалистом предметной области. В любой предметной области формируется профессиональный жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и воспринимаются разными специалистами по-разному. В то вынужден употреблять те выражения, которые наиболее понятны экспертам. Поскольку формальные определения часто сложны, восприятия, аналитик вынужден употреблять профессиональный жаргон, а, чтобы не возникло неоднозначных трактовок, в словаре стрелок каждому понятию можно дать расширенное и, если это необходимо, формальное определение (рис. 27). Рис. 27 Начальный этап построенияICOM (аббревиатура от Input, Control, Output и Mechanism) - коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (рис. 28).Рис. 28 Диаграммы декомпозиции работы А0 с кодами ICOM 3.3 Создание диаграммы дерева узлов и диаграммы FEOДиаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно, чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. Впрочем, BPwin имеет мощный инструмент навигации по модели - Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде, однако этот инструмент не является составляющей стандарта IDEF0.Для создания диаграммы дерева узлов следует выбрать в меню пункт Diagram/Add Node Tree (рис. 29).Рис. 29 Диалог настройки диаграммы дерева узлов Создадим диаграмму дерева узлов моделиВозникает эксперт создания диаграммы дерева узлов Node Tree Wizard. В первом диалоге эксперта необходимо внести имя диаграммы дерева узлов, узел верхнего уровня и глубину дерева - Number of Levels (по умолчанию 3). Поскольку дерево узлов не обязательно в качестве верхнего уровня должна иметь контекстную работу и иметь произвольную глубину.В одной модели можно создавать множество диаграмм деревьев узлов. Имя дерева узлов по умолчанию совпадает с именем работы верхнего уровня, а номер диаграммы автоматически генерируется как номер узла верхнего уровя плюс литера «N», например A0N. Если в модели создается два дерева узлов, имеющих в качестве верхнего уровня одну и ту же работу, то по умолчанию диаграммы получат идентичные номер и имя. Поэтому рекомендуется при создании диаграммы дерева узлов внести имя диаграммы, отличное от значения по умолчанию (рис. 29).Рис. 29. Диаграмма дерева узлов Обеспечить продукцией Выполним модификацию дерева узлов, щелкнув правой кнопкой мышки по свободному пространству в диаграмме и вызовем контекстное меню с командами редактирования (рис. 30).Рис. 30 Редактирование диаграммыСледующим шагом создадим диаграмму FEO (Diagram-Add-FEO)Рис. 31 Создание диаграммы FEO Диаграммы «только для экспозиции» (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку, по сути, являются просто картинками - копиями стандартных диаграмм и не включаются в анализ синтаксиса. Например, работа на диаграмме FEO может не иметь стрелок управления и выхода.С целью обсуждения определенных аспектов модели с экспертом предметной области может быть создана диаграмма только с одной работой и одной стрелкой, поскольку стандартная диаграмма декомпозиции содержит множество деталей, не относящихся к теме обсуждения и дезориентирующих эксперта. Но если FEO используется для иллюстрации альтернативных точек зрения (альтернативный контекст), рекомендуется все-таки придерживаться синтаксиса IDEF0. Для создания диаграммы FEO следует выбрать пункт меню Diagram/Add FEO Diagram. В возникающем диалоге Add New FEO Diagram следует указать имя диаграммы FEO и тип родительской диаграммы.Рис. 32. Диалог создания FEO-диаграммы Новая диаграмма получает номер, который генерируется автоматически, на рисунке 33 отображен номер родительской диаграммы по узлу + постфикс F, A0F.Рис. 33 Диаграмма FEOВ практической части диплома была рассмотрена конкретная технология разработки, основанная на решениях создания бизнес-модели предприятия. Было выбрано средство BPwin, поддерживающее методологию IDEF0 и DFD. В результате проведенных исследований выяснено, что методология IDEF0 позволяет построить иерархическую систему диаграмм-единичных описаний фрагментов системы. Алгоритм функционирования следующий: сначала производится описание системы и её взаимодействия с окружающим миром (контекстная диаграмма), после чего производится функциональная декомпозиция.-система разбивается на более мелкие- и так далее, до достижения нужной степени подробности. ЗаключениеЛюбой производственный проект начинается с планирования. Планирование - это процесс разработки и последующего контроля за ходом реализации плана и его корректировки в соответствии с изменяющимися условиями, т.е. планирование - это процесс обработки информации по обоснованию предстоящих действий, определение экономически эффективных способов достижения цели. Для достижения наибольшего экономического эффекта предприятие должно использовать такие методы производства, которые являются эффективными, как с технологической стороны, так и с экономической точки зрения. Важными факторами также будет эффективное распределение ресурсов, система цен, эффективность и другие.В результате анализа деятельности и структуры предприятия «АНХК», были сформированы достаточно цельные и систематизированные знания в области исследования, которые в дальнейшем будут реализованы в построении диаграмм бизнес процесса.Анализ проблем автоматизации показал, что на предприятии не существует единой корпоративной информационной системы, не существует и единого банка данных, что порождает несогласованность и не оперативность в работе подразделений.Предприятию рекомендуется, используя инструментальную среду моделирования, выполнить проектирование АИС, разработать единый банк информации, использовать для работы распределенные системы обработки информации. А так же использовать технологии оптимального календарного планирования по кварталам, месяцам. На примере конкретного предприятия выполнено построение моделей бизнес процессов, рассмотрено существующее положение дел в изучаемой области, произведен детальный анализ алгоритмов построения бизнес процессов средствами инструментальной среды BPwin. Сделаны следующие выводы: 1. реализацию крупных проектов следует разбивать на стадии анализа проектирования, непосредственного кодирования, тестирования и сопровождения; 2. крупный проект невозможно реализовать в одиночку; 3. жизненный цикл ИС равен примерно 2 годам, столько же требуется времени на разработку ИС, для создания крупной информационной системы жизненно необходим инструмент, который бы значительно уменьшал время разработки ИС; 4. так как жизненный цикл довольно продолжителен и существует возможность получить на последней стадии продукт, который будет не совсем удовлетворять новым требованиям, жизненно необходима инструментальная среда способная быстро приспособится к изменившимся требованиям установлено, что таким требованиям вполне удовлетворяет среда BPwin, такие модели представляют информационные потребности в удобном и наглядном для восприятия виде, что делает их хорошим средством коммуникации между проектировщиками и пользователями в процессе уточнения постановки задач. Любой разработчик заинтересован, чтобы описание концептуальной модели было использовано для создания спецификаций, описывающих структуру и основные компоненты будущей системы. Полученные в BPwin компоненты системы могут быть преобразованы в реальные объекты базы данных, экранные формы и отчеты. Целью дипломной работы являлось изучение проблем совершенствования информационного обеспечения управления организацией, построение модели основных бизнес процессов на предприятии. В результате выполнения дипломной работы, поставленные цели и задачи выполнены. Список литературы1. О недрах: федеральный закон РФ от 21.02.1992 г. №2395-1 (ред. от 29.06.2004 г.) [электронный ресурс] // Консультант Плюс. Версия Проф.2. Армяков М. Русские Инвесторы / М. Армяков // Экономика России: ХХI век. - 2002. - №2. - С. 7-10.3. Анисимов В.В. 50 лет успешной вахты. Научно-технические достижения и передовой опыт / В.В. Анисимов // Нефтепереработка и нефтехимия. - 2003. - №8. - С. 3-4.4. Батюнин В.А. Снижение энергозатрат - путь к повышению эффективности производства / В.А. Батюнин, В.Ю. Абрамов // Нефтепереработка и нефтехимия. - 2003. - №8. - С. 52-53.5. Безруков А.А. Аппетитные соседи / А.А. Безруков // Нефтегазовая отрасль. - 2004. - №7. - С. 23-24. 6. Белобородов К.Г. Экспортировать бензин станет дороже / К.Г. Белобородов // Коммерсант. - 2004. - №194. - С. 6-7. 7. Беспалов Ю.А. О закрытии ряда химических производств ОАО «Ангарская нефтехимическая компания» / Ю.А. Беспалов // Время. - 2001. - 18 февр. 8. Бирюков Н.Н. Бизнес и нефть / Н.Н. Бирюков // БИКИ. - 2001. - №2. - С. 39. 9. Воеводин Г.А. Нефть и Россия: планы на будущее / Г.А. Воеводин // Ведомости. - 2004. - №32. - С. 9. 10. Воронина Н.В. Мировой рынок нефти: тенденции развития и особенности ценообразования / Воронина Н.В. // Практический маркетинг. - 2003. - №10. - С. 12-18. 11. Вяземский О.В. Сколько стоит наше будущее / О.В. Вяземский // Ведомости. - 2004. - №37. - С. 12. 12. Гаврилова Н.А. Итоги деятельности ОАО «АНХК» / Н.А. Гаврилова // Восточно-Сибирская правда. - 2004. - №87. - С. 8. 13. Дэниел О'Лири ERP системы. Современное планирование и управление ресурсами предприятия. Выбор, внедрение, эксплуатация М.: ООО «Вершина», 2004. - 272 с, [Пер. с англ. Ю.И. Водопьяновой 14. Меняев М.Ф Информационные технологии управления: Книга 3: Системы управления организацией М.: Омега-Л, 2003. - 464 с 15. Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие М.: Гелиос АРВ, 2002. - 368 с., ил 16. Б.Н. Гайфуллин, И.А. ОбуховАвтоматизированные системы управления предприятиями стандарта ERP/MRPII. Производственное издание М. «Богородский печатник», 2001, 104 с 17. Петров В. Н Информационные системы СПб.: Питер, 2002. - 688 с 18. IEEE Standard Glossary of Software Engineering Terminology IEEE Std 610.12-1990 19. Вигерс Карл Разработка требований к программному обеспечению Пер, с англ. - М.:Издательско-торговый дом «Русская Редакция», 2004. -576 с.: ил 20. Леффингуелл Д., Уидриг ДПринципы работы с требованиями к программному обеспечению М.: ИД «Вильямс», 2002 21. Алистер Коберн Современные методы описания функциональных требований к системам М.: издательство «Лори», 2002. - 263 с 22. Мацяшек Лешек Анализ требований и проектирование систем. Разработка информационных Пер. с англ. - М.: Издательский дом «Вильямс», 2002. - 432 с.: ил. - Парал. тит. Англ 23. Орлик С., Булуй Ю Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия. Программные требованияCopyright © Сергей Орлик, 2004-2005 24. IEEE Guide to the Software Engineering Body of Knowledge(1) - SWEBOK®, 2004 25. ГОСТ Р ИСО/МЭК 12207/99. Государственный стандарт РФ. Информационная технология. Процессы жизненного цикла информационных систем Издание официальное. - М., 1999 26. Каменова, Громов Моделирование бизнеса. Методология ARIS М.: Весть-МетаТехнология, 2001 27. А. Якобсон, Г. Буч, Дж. Рамбо Унифицированный процесс разработки программного обеспечения СПб.: Питер, 2002. - 496 с 28. Э.В. Попов Искусственный интеллект: в 3 книгах, кн. 2. Модели и методы М.: Радио и связь. - 1990 29. Марка Д.А Методология структурного анализа и проектирования СПб.: Питер, 1995. - 235 с 30. Марка Д., МакГоуэн К Методология структурного анализа и проектирования М.: МетаТехнология, 1993 31. ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания 32. Фаулер М, Скотт К UML в кратком изложении. Применение стандартного языка объектного моделирования Пер. с англ. - М.:Мир, 1999. - 191 с., ил 33. Алистер Коберн Современные методы описания функциональных требований к системам 34. Леоненков Самоучитель UML 35. Маклаков С.В Bpwin Erwin Case-средства разработки информационных систем Москва «ДиалогМифи» - 2000 36. ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению» 37. Соммервилл, Иан Инженерия программного обеспечения, 6-е издание Пер. с англ. - М.: Издательский дом «Вильямс», 2002. - 624 с.: ил. - Парал. тит. англ 38. Орлик С Программная инженерия. Качество программногообеспечения (Software Quality) Copyright © Сергей Орлик, 2004-2005 39. Калянов Г. Н Консалтинг при автоматизации предприятий: Научно-практическое издание Серия «Информатизация России на пороге XXI века». - М.: СИН-ТЕГ, 1997 40. Мальков А.С. Проект автоматизации финансово-хозяйственной деятельности ОАО «Ангарская нефтехимическая компания». - М.: 2002 г. 41. Галкин А.А. Дегтярь Р.М. Теория и практика оценки эффективности эксплуатации ERP системы. - М.: Корпоративный менеджмент. №7 2002 г. 42. Высочин С.Н., Фролов Е.Е. Управление цеховым складом, как элемент системы ресурсосберегающей организации производства. - М.: САПР и графика. №11, 2000 г. 43. Шебек С.С. Практика разработки корпоративных стандартов. - СПб: Планета КИС. 2000 г. 44. Шаракшанэ А.С., Халецкий А.К., Морозов И.А. Оценка характеристик сложных автоматизированных систем. - М., Машиностроение, 1993. - 272 с. 45. Чембровский О.А., Топчеев Ю.И., Самойлович Г.В. Общие принципы проектирования систем управления. - М., Машиностроение, 1972. -414 с. 46. Уайт О.У. Управление производством и материальными запасами в век ЭВМ. М.: Прогресс. 1978, C. 302. //Oliver W. Wight. Production and inventory management in the computer age. Macmillan of Canada, 1974 47. Компьютерные системы и сети: Учеб пособие / В.П. Косарев и др. / Под ред. В.П. Косарева и Л.В. Еремина. - М.: Финансы и статистики, 1999.
Страницы: 1, 2, 3, 4, 5, 6, 7
|
