Резюме
Многие проекты разработки программного обеспечения терпят неудачу, или конечный результат не соответствует ожиданиям заказчика или конечного пользователя или самих разработчиков. Для клиента проект разработки программного обеспечения может быть неудачным, потому что он занял больше времени, чем ожидалось, или хуже, потому что полученное программное обеспечение не решает проблемы, для которых оно было заказано.
Есть несколько факторов, которые могут привести к провалу проекта разработки программного обеспечения. Бизнес-моделирование на стадии замысла проекта разработки программного обеспечения является одним из наиболее важных видов деятельности, и во многих случаях оно не выполняется с необходимой глубиной, в результате чего отсутствует полное понимание задействованных процессов. компьютеризация и ложное понимание между клиентами (или пользователями) и командой разработчиков относительно работы, которую необходимо выполнить.
Дисциплина бизнес-моделирования RUP (Rational Unified Process) предлагает набор артефактов для моделирования процессов организации, разработка всех этих артефактов может быть медленной и обременительной, что отрицательно сказывается на эффективном прохождении через эту дисциплину. Настоящая работа предлагает альтернативу артефактам дисциплины бизнес-моделирования методологии RUP: IDEF, это метод моделирования системы с использованием определенной графической структуры. Он варьируется от информационного моделирования до объектно-ориентированного анализа и проектирования.
Ключевые слова
IDEF, бизнес-процессы, бизнес- моделирование, разработка программного обеспечения, RUP
Введение
Несмотря на важность знания бизнес-процессов, которые будут поддерживать компьютерную систему, общепринятой практикой является недооценка стадии, на которой эта информация собирается во время цикла разработки программного обеспечения. Команды разработчиков, исходя из требований клиентов относительно того, насколько быстро им необходимо запустить и запустить программный продукт, обычно уделяют мало внимания полному пониманию бизнеса. Если принять во внимание, что подавляющее большинство организаций не представляют схематично, каковы их процессы, и что некоторые из наиболее часто используемых методологий разработки программного обеспечения, такие как унифицированный процесс разработки (RUP, аббревиатура на английском языке),предложите большое количество артефактов для этого моделирования, построение которых может стать медленным и громоздким, тогда будут созданы все условия, чтобы бизнес не моделировался с той строгостью, которой он заслуживает.
Результатом этой практики являются программные продукты, ориентированные на потребности или требования, выдвинутые клиентом, который иногда не может точно определить, как программная система может улучшить свою линейку продуктов или услуг. Кроме того, программные продукты часто получаются с чрезвычайно высокими затратами на внедрение и далеки от объективной реальности организации, которая намеревается их использовать. Разработчики склонны к творческому подходу, стремясь реализовать свои профессиональные качества в создании идеальных компьютерных систем, при этом дистанцируясь от реальности бизнеса и клиентов.
Технологические возможности и экономическая ситуация в организации, подлежащей автоматизации, не являются основной целью бизнес-моделирования, предлагаемого RUP. Однако, принимая во внимание эти элементы, пытаясь повлиять на них положительно, если это должно быть целью создания программного продукта, следовательно, на этом начальном этапе считается чрезвычайно важным, чтобы группа разработчиков применила эти дополнительные знания.
В этой статье предлагается интеграция некоторых методов IDEF (интегрированных методов определения) с методологией RUP с целью использования этих методов в качестве альтернативы артефактам, предлагаемым в рамках данной методологии бизнес-моделирования. Необходимо отметить, что представленной информации о методиках моделирования IDEF недостаточно для применения представленных здесь идей, позже необходимо будет изучить их более подробно. Это предложение основано на опыте авторов во время производства специального программного обеспечения для Боливарианской Республики Венесуэла, продукта кубинско-венесуэльских соглашений в свете ALBA.
развитие
IDEF
В 1970-е годы военно-воздушные силы США разработали программу интегрированного автоматизированного производства (ICAM). Программа ICAM выявила потребность в улучшении методов коммуникации и анализа для персонала, задействованного в производстве. Результатом проекта ICAM стала серия методов, известных как IDEF (интегрированные методы определения). Первоначальная концепция включала:
- IDEF0: используется для представления действий или процессов. IDEF1: используется в качестве модели для представления и структурирования информации. IDEF2: используется для представления моделей, которые меняются во времени.
В 1983 году ВВС США разработали интегрированную систему информационной поддержки на основе IDEF1, создав IDEF1X (расширенный IDEF1).
Шли годы и использование этих методов, IDEF продолжало свое развитие и появлялись новые версии: IDEF3, IDEF4 и IDEF5. В настоящее время существует несколько инструментов, упрощающих моделирование с помощью этих методов.
IDEF0
IDEF0 - это метод моделирования, разработанный для представления в структурированном и иерархическом виде действий, составляющих систему или компанию, а также объектов или данных, которые поддерживают взаимодействие этих действий. Модель IDEF0 состоит из иерархической серии диаграмм, которые позволяют через уровни детализации описывать функции, указанные на верхнем уровне. В верхней части модели взаимодействие между представленными видами деятельности позволяет визуализировать фундаментальные процессы, поддерживающие организацию. Графическими элементами, используемыми для построения диаграмм IDEF0, являются таблицы и стрелки.
Семантика использования этих графических элементов следующая:
Действие: обозначено рамкой, обозначает функцию, процесс или преобразование.
Вход: представлен стрелкой, входящей с левой стороны действия, он указывает материалы или информацию, которые будут преобразованы в действие, чтобы получить выход.
Вывод: он представлен стрелкой, выходящей из правой части действия, он указывает объекты или информацию, полученную при возникновении действия.
Контроль: представлен стрелкой, вводимой сверху, он указывает на правила, которые определяют, выполняется действие или нет. Например: стандарты, руководства, правила, политики и т. Д.
Тема: представлена стрелкой, входящей снизу, она указывает ресурсы, которые выполняют действие. Например: люди, техника и т. Д.
Преимущества IDEF0 для моделирования бизнес-процессов
- Это позволяет отобразить процесс в хронологическом порядке. Описывается ориентированный на конечного потребителя поток этого бизнеса, охватывающий все виды деятельности организации, выполняющей запрос продукта или услуги, сделанный клиентом, таким образом представляя «цепочку создания стоимости» компании (процесс моделируется для каждого типа продукта или услуги, которые предоставляет компания). Это простая запись (на основе прямоугольников и стрелок), которую любой сотрудник может использовать для описания того, что он делает в бизнесе. Привлечение сотрудников организации к моделированию бизнеса экономит время, работая одновременно в нескольких областях, а также позволяет получить более точную модель, поскольку она была разработана ее главными действующими лицами. Это позволяет включать в поток данные, которые входят в деятельность и покидают ее, а также бизнес-правила и участников.все в одном и том же виде. Это позволяет разделить деятельность как процесс по очереди. Это позволяет обнаружить организационные проблемы в бизнесе, которые необходимо исправить, чтобы «не компьютеризовать хаос», а организовать бизнес, а затем компьютеризировать его.
IDEF3
IDEF3 - это метод моделирования для представления рабочего процесса процесса, а также участвующих в нем объектов из описания, данного экспертом. Он позволяет документировать процесс на подробном уровне, облегчая его анализ путем выявления и сбора важнейших знаний.
Основными компонентами, которые IDEF3 использует в своем представлении, являются: единица работы, ссылки, соединения и ссылки.
Единица работы: представляет действие, всегда имеет уникальный идентификатор и может иметь ссылку, связанную с действием IDEF0.
Лиги: представляют собой ограничивающие отношения между действиями, являются однонаправленными, могут начинаться и заканчиваться в любой части действия («прямоугольник»), должны быть помечены.
Есть три типа лиг:
Временной приоритет
Исходный процесс должен быть завершен, прежде чем целевой процесс сможет запуститься.
Поток объектов
Он подчеркивает участие объекта между двумя процессами, указывая временное преимущество, исходный процесс должен завершиться до того, как целевой процесс может завершиться.
реляционный
Наличие взаимосвязи между связанными процессами. Исходный процесс начнется до того, как закончится целевой процесс.
Связи: они служат для представления:
- Точки, в которых процесс разветвляется на несколько потоков Точки, в которых несколько процессов сходятся в один процесс. ŸВременность (синхронность / асинхронность) в потоке действий процесса.
Типы филиалов:
Дивергенция (разветвление): распределяет поток процесса, прекращение действия вызывает активацию нескольких действий.
- Конвергенция (Fan-in): завершение нескольких действий объединяет начало действия.
Ссылки: представляют собой специальные символы, чтобы привлечь внимание читателя к другим важным частям модели.
Вот некоторые из существующих типов ссылок:
- Object: описывает участие важного объекта в действии GOTO: конструирует циклы (повторяющаяся последовательность действий) UOB (UnitOfBehavior): включает уже описанное действие без включения цикла Примечание: документирует любую важную общую информацию из любого графика (активность, соединение) ELAB (проработка): Подробно задокументируйте некоторый график.
Преимущества IDEF3
- Он позволяет документировать процессы для стандартизации или в качестве руководства для новых участников процесса и, таким образом, сокращает кривую обучения. Он обеспечивает механизм, позволяющий фиксировать временную последовательность процесса и логику принятия решений, которая на него влияет. Он служит инструментом для анализа существующих процессов. Это позволяет вам разрабатывать и тестировать новые процессы, прежде чем вносить фактические изменения, которые могут оказаться очень дорогими.
Простое сравнение обоих методов позволяет проиллюстрировать, как они дополняют друг друга, по-разному влияя на одни и те же аспекты, что позволяет рассматривать их в целом.
IDEF в методологии RUP для моделирования бизнеса
Описание деятельности
Модель глобальных процессов:
- Вовлеченные: клиенты и группа разработчиков. Цель: определить бизнес-процессы организации, ее цели, задействованные ресурсы и т. Д. Методика: IDEF0 Описание: В этой деятельности бизнес-процессы организации определяются посредством встреч с задействованные менеджеры и рабочие. Графические элементы, составляющие технику IDEF0, объясняются всем задействованным менеджерам и работникам, и совместно разрабатывается Модель процесса, соответствующая AS - IS этой техники. AS - IS - это не что иное, как моделирование глобальных процессов организации в ее текущей ситуации.
Определите лишние действия:
- Участвует: группа разработчиков. Цель: выявить излишние действия, которые могут существовать в процессах организации. Методика: анализ Описание: в этом действии модель процесса, выполняемая организацией, анализируется для выявления действий, которые могут считаться излишними., Излишняя деятельность - это та, от которой можно отказаться, не влияя на конечный результат смоделированного процесса, либо потому, что она не дает никакого результата, либо потому, что полученный результат может быть частью другой деятельности, таким образом исключая субъекта из процесса.
Модельные усовершенствованные глобальные процессы:
- Участвует: команда разработчиков. Цель: обновить модель процесса с помощью выявленных улучшений. Методика: IDEF0. Описание: в этом действии модель процесса, выполняемая организацией, обновляется, устраняя выявленные лишние действия. В модель добавлено краткое описание того, как выполняется каждое действие. На этом этапе в модель вносятся изменения, которые подразумевают предложение по улучшению процессов. Эти изменения должны быть основаны на изучении техники, проведенной до этапа бизнес-моделирования командой разработчиков по аналогичным бизнес-процессам на национальном и международном уровнях. Эта новая модель соответствует модели процесса IDEF0 TO - BE.
Подтвердите предлагаемые улучшения с клиентом:
- Участвуют: клиенты и группа разработчиков. Цель: договориться между клиентами и командой разработчиков о том, какими должны быть процессы в организации, прежде чем переходить к компьютеризации. Методика: встреча Описание: в этом упражнении команда Разработка представляет клиенту усовершенствованную модель глобальных процессов, чтобы он мог указать свое согласие с предложением или сделать соответствующие указания.
Подробно комплексные мероприятия:
- Участвует: группа разработчиков. Цель: детально моделировать действия большей сложности, необходимые для автоматизации организации. Методика: IDEF3 Описание: в этом действии модель процесса, выполняемая организацией, обновляется, устраняя выявленные лишние действия., На этом этапе в модель можно внести другие изменения, которые подразумевают предложение по улучшению процессов клиента. Эти предложения по дополнительным улучшениям должны быть основаны на художественном исследовании аналогичных процессов на национальном и международном уровнях, проведенном командой разработчиков, до стадии бизнес-моделирования.
Подтвердите подробное описание у клиента:
- Вовлеченные: клиенты и команда разработчиков. Цель: установить соглашение между клиентами и командой разработчиков о том, как подробно выполняются комплексные действия организации, которые должны быть автоматизированы. Разработка представляет клиенту подробное описание выбранных комплексных мероприятий, чтобы он выразил свое согласие с предложением или сделал соответствующие указания.
Установите границы проекта:
- Участвуют: клиенты и команда разработчиков. Цель: установить соглашение между клиентами и командой разработчиков о том, какие процессы организации будут компьютеризированы. Методика: встреча Описание: эта деятельность определяется посредством обсуждения между клиентами. и команда разработчиков, какие процессы нужно будет компьютеризовать. Для этого за основу взята Улучшенная модель глобальных процессов.
Ссылки
Альварес Ромеро, Эдуардо; Пуэйо, Даниэль. Определение интеграции для моделирования функций (IDEF0) взято из
Гарсия, Ана М. Моделирование бизнес-процессов. Примечания к курсу.
Моделирование процессов, теория систем, Университет Вальпараисо, взято из
Библиография
IDEFØ Семейство методов IDEF Структурный подход к моделированию и анализу предприятия
