Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Информационные технологии и моделирование бизнес-процессов

Этапы процесса разработки бизнес-модели

Корпорация Rational Software в 1999 году выпустила на рынок структурированную базу знаний под названием Rational Unified Process (RUP), которая представляет собой набор исчерпывающих рекомендаций для создания практически любых моделей и программных продуктов. Вобрав в себя опыт лучших разработок, RUP подробно описывает когда, кто и что должен делать в проекте, чтобы в результате получить смоделированную систему установленных сроков, с определенной функциональностью и в рамках отведенного бюджета.

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

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

Схема процесса разработки

Рис.18.9. Схема процесса разработки

Вся разработка ПО рассматривается в RUP как процесс создания модулей. Любой результат работы проекта, то исходные тексты, объектные модули, документы, которые передаются пользователю, модели - это подклассы всех модулей проекта. Каждый участник проектной группы создает свой модуль и несет за него ответственность: программист создает программу, руководитель - проектный план, а аналитик - модели системы. RUP - позволяет определить когда, кому и модуль необходимо создать, доработать или использовать.

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

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

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

В фазе исследования уточняются требования, выполняется высокоуровневый анализ и проектирование для построения базовой архитектуры; разрабатывается план для фазы построения.

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

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

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

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

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

o риски, связанные с требованиями;

o технологические риски;

o риски, связанные с квалификацией персонала.

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

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

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

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

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

Резюме

Для моделирования бизнес-процессов используется несколько различных методов, в основе которых лежит как структурный, так и объектно-ориентированный подходы к моделированию: SADT (IDEF0) IDEF3; DFD; ARIS; Ericsson-Penker; Rational Unified Process, причем последние три метода используют UML.

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

Ключевые слова

Бизнес-процесс, моделирование, модель, варианты использования (Use Case), диаграмма, каноническая диаграмма, UML, нотация, класс, ассоциация, кратность, объектно-ориентированный метод, процесс разработки бизнес-модели, риски.

Вопросы и задания для обсуждения и самопроверки:

► Назовите распространенные методы моделирования бизнес-процессов.

► Опишите характеристики бизнес-модели, построенной по методу SADT.

► Назовите основную задачу моделирования потоков данных.

► Приведите типы бизнес-моделей, поддерживает метод ARIS.

► Определите назначение универсального языка моделирования UML.

► Дайте определение диаграммы как средства UML. Какие диаграммы входят в состав интегрированной модели сложной системы?

► Дайте определение диаграммы и нотации. Проиллюстрируйте понятие кратности в определении нотации диаграммы классов.

► Какие преимущества объектно-ориентированных методов моделирования? Опишите этапы разработки бизнес-модели.

► Охарактеризуйте понятие риска.

 
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 
Предметы
Агропромышленность
Банковское дело
БЖД
Бухучет и аудит
География
Документоведение
Естествознание
Журналистика
Инвестирование
Информатика
История
Культурология
Литература
Логика
Логистика
Маркетинг
Математика, химия, физика
Медицина
Менеджмент
Недвижимость
Педагогика
Политология
Политэкономия
Право
Психология
Региональная экономика
Религиоведение
Риторика
Социология
Статистика
Страховое дело
Техника
Товароведение
Туризм
Философия
Финансы
Экология
Экономика
Этика и эстетика
Прочее