Законы существования текстов в обществе 32
| Вид материала | Закон |
- Регулятивные ууд, 48.56kb.
- -, 603.7kb.
- -, 1052.37kb.
- Электронные коллекции текстов, 76.81kb.
- Направление: Искусство и гуманитарные науки, 1316.91kb.
- -, 79.32kb.
- Языковая политика и законы о языке, 1122.28kb.
- Жанров и pr-текстов. Специфика содержания pr-текстов, 98.76kb.
- Законы сохранения и принципы симметрии, 283.17kb.
- Б. Е. Большаков Механизмы формирования идеалов и ценностей для управления безопасностью, 924.23kb.
Глава 3. Риск, связанный с разработкой
и внедрением систем автоматизации
Однако разработка и внедрение столь необходимых систем автоматизации – непростая и, как показывает практика, рискованная задача. Обратившись к отчёту The Standish Group (консалтинговая компания, специализирующаяся на оценке IT проектов), мы увидим, что 31% IT-проектов прекращаются незавершенными, 53% всех проектов превышают запланированный бюджет на 89%. Задержки по срокам среди 84% завершившихся проектов составляют в среднем 222% сверх запланированного. Только 12% проектов выполняется в срок и без превышения бюджета. И всего лишь 7% реализованных продуктов по своим функциональным возможностям полностью удовлетворяют ожиданиям заказчиков. И это при том, что средняя стоимость одного проекта, (т.е. одного элемента приведённой выше схемы!), составляет (статистика для США) порядка $2 322 000 для крупной компании, $1 331 000 для средней, и около $434 000 для предприятий малого бизнеса. Естественно, возникает вопрос: в чём причина столь печального положения дел? То же статистическое исследование показывает, что, по мнению разработчиков ПО для бизнеса, неудачи связаны в первую очередь:
- с недостаточным участием пользователей в разработке (13% респондентов),
- неполнотой сформулированных требований и спецификаций (13%),
- изменением требований к системе в процессе разработки (9%),
- нереалистичными ожиданиями со стороны заказчика (10%),
- недостаточным планированием (8%).
Ещё 2 причины получили в сумме 20% «голосов», вариант «другое» – 28%.
Глава 4. Онтологическое описание бизнес-
процесса: теория и практика
Предпосылка использования онтологий для описания БП:
уменьшение риска при разработке программного обеспечения
Оказывается, что тщательное моделирование бизнес-процессов заказчика может помочь заметно уменьшить риск, как при внедрении готовых решений, так и при разработке индивидуальных проектов. Каким образом это достигается?
Действительно, как уже описывалось выше, моделирование бизнес-процессов играет всё более важную роль в разработке программного обеспечения для бизнеса, и обычно проект начинается с анализа бизнес-процессов заказчика. Для этого проводятся консультации с экспертами в соответствующей предметной области. Затем следует формальное описание БП, выполняемое людьми с хорошими знаниями в сфере IT. В последнее время всё чаще применяются вспомогательные инструменты, предоставляющие средства для графического описания бизнес-процессов, их моделирования и оптимизации.
Описание бизнес-процесса в неявной форме содержит функциональные требования к разрабатываемому продукту. Однако просто описать БП как набор элементарных операций, связанных через поток передачи управления (process control flow), для этой цели недостаточно. Чтобы выражать требования в полном объёме, описание процесса должно явно указывать на задействованные в нём сущности. Так, например, бизнес-действие1 выполняется некоторым субъектом («ролью») и в нём участвуют бизнес-документы и бизнес-объекты.
Тут перед разработчиком описания бизнес-процесса встаёт дилемма. С одной стороны, на рынке нет инструментов описания процессов с достаточно богатой метамоделью, чтобы выразить все связанные с процессом функциональные требования, не говоря уже о нефункциональных, таких как производительность и надёжность. С другой стороны, риск для проекта наиболее высок именно на этапе бизнес-моделирования. Если требования к системе будут поняты неправильно, то велика вероятность, что какая-то часть необходимой функциональности не будет реализовываться, а замечен этот факт будет лишь на завершающей стадии разработки. Таким образом, очень важны любые средства, позволяющие отслеживать ошибки как можно раньше и тем самым уменьшать риск провала проекта. И чем полнее и точнее будет описание бизнес-процесса, тем лучше.
Недостатком большинства программных продуктов, предназначенных для моделирования БП, является слабая интеграция с CASE-средствами. В худшем случае, проектировщикам ПО приходится вручную повторно вводить описание бизнес-процессов в CASE-систему. Таким образом, объединённая разработка описания БП и объектной модели остаётся несбыточной мечтой.
Когда согласованность между требованиями к разрабатываемой системе и определяющими архитектуру решения артефактами2 поддерживается вручную, вероятность того, что в конце концов она будет безнадёжно нарушена, приближается к 100%. А системы разработки ПО предлагают очень мало средств для решения этой проблемы. Практика показывает, что даже соответствие между бизнес-моделями и построенными на их основе моделями ПО (например, UML-диаграммами), нарушается очень быстро при изменении или дополнении требований к системе.
Основная причина потери синхронизации – наличие принципиальных различий между метамоделями описания требований к проекту и объектно-ориентированного дизайна, который лежит в основе большей части современных проектов разработки ПО. Эти различия проистекают из того, что функциональные требования, как правило, описывают пользовательский интерфейс, алгоритмы (процесс обработки заказа), содержащие информацию объекты (заказ как документ) и т.п. А объектно-ориентированная модель работает с понятиями классов, их свойств и поведения, взаимоотношений с другими классами. И очень сложно сохранять согласованность, когда речь идёт о разных вещах и с использованием разной терминологии.
Рис. 4. Потеря информации при проектировании – закон природы?
Профессионалы уже давно говорят о существовании зияющей бреши в традиционной схеме разработке ПО для бизнеса: хотя бизнес-правила играют центральную роль в каждой компании, им на протяжении многих лет практически не уделяется внимание. Очень часто на этапе формулирования требований ими в большей или меньшей степени пренебрегают. Это приводит к закономерному результату: ни проектировщики ПО, и работающие с ними бизнес-аналитики не имеют полного и непротиворечивого представления о предъявляемых к проекту требованиях. И нет ничего удивительного в том, что столь многие проекты терпят неудачу или требуют очень серьёзных усилий для исправления ошибок, допущенных на ранних стадиях разработки. О серьёзности данной проблемы свидетельствует приведённая выше статистика.
Современные CASE-средства упрощают и ускоряют процесс разработки ПО и позволяют его частично автоматизировать. Так, на основе модели системы может быть получено от 40% до 100% её кода.
Напротив, получение технических требований и разработка архитектуры системы остаются трудоёмкими и чреватыми ошибками задачами, и часто сопровождаются потерями ценной информации.
Общая недостаточная точность и полнота информации, хранимой по частям в нескольких разных местах, никак не способствует её правильному пониманию. Следовательно, желательно хранить всю информацию по проекту в одном месте. А для ускорения процесса проектирования и разработки, должна быть возможной машинная обработка этой информации.
Из сказанного следует, что для того, чтобы избежать упомянутых выше рисков и оптимизировать процесс проектирования, необходимо:
- Переложить задачу определения требований к разрабатываемому продукту на бизнес-аналитиков (сотрудников компании-заказчика) – для достижения большей точности в определении требований.
- Метамодель, используемая для описания БП, должна быть достаточно богатой, чтобы позволять описать все функциональные требования и, возможно, часть нефункциональных.
- Необходимо использовать интегрированный подход, чтобы описание БП и определяющие архитектуру системы артефакты влияли друг на друга и согласованность поддерживалась автоматически. В идеале, должно быть возможным автоматическое получение этих артефактов на основе описания БП.
Рис. 5. Центральная роль бизнес-аналитика
Подводя итог, сказанного выше:
Постоянная опасность потери ценой информации в процессе разработки ПО усиливает потребность в по-настоящему интегрированном подходе.
Такой подход должен позволить бизнес-специалистам и архитекторам ПО использовать единую информационную базу, в которой можно было бы хранить требования, описания бизнес-процессов и набор артефактов объектно-ориентированного проектирования.
В идеале, она должна содержать эту информацию в форме, не накладывающей никаких зависимостей от платформ и производителей ПО. По сути, такая база должна содержать знания. Её целостность должна поддерживаться автоматически.
В последние годы предпринималось несколько попыток сделать содержимое World Wide Web понятным для программных агентов, осуществляющих поиск информации в рамках проекта Semantic Web. Результатом этих усилий стало появление языков для кодирования знаний: Resource Description Framework (RDF) и Web Ontology Language (OWL), о которых ниже будет рассказано более детально.
Задача сделать информацию «понятной» для машин, стоящая в обоих случаях, может быть обобщена. Необходимо описать некоторую предметную область, т.е. указать относящиеся к ней объекты (сущности), их качества и отношения. Такие описания существуют. Это – онтологии.
Что такое онтология бизнес-процесса?
Поскольку исторически, понятие онтологии появилось в одной из ветвей философии, называемой метафизикой, которая изучает устройство реального мира, то основной характерной чертой онтологического анализа является, в частности, разделение реального мира на составляющие его классы объектов и определение их онтологий, или же совокупности фундаментальных свойств, которые определяют их изменения и поведение. Онтология определяет термины и понятия, используемые для описания и представления области знаний, а также отношения между ними. Таким образом, онтология включает:
- Понятия (объекты) рассматриваемой предметной области (домена).
- Отношения между объектами.
- Характеристики (свойства) объектов и их возможные значения
- Ограничения и правила, которым подчиняются объекты.3
Так же, как в объектно-ориентированной парадигме после определения объектов могут быть созданы их экземпляры, можно дополнить онтологию информацией о конкретных сущностях. Эта информация в сочетании со структурой онтологии есть знание. Базы знаний, полученные на основе онтологий, используются в вопросно-ответных и экспертных системах. С помощью онтологий представляют свои знания и интеллектуальные агенты, на основе которых строятся многие приложения электронной коммерции, поисковые системы и другие программные продукты.