ПОИСК
Это наилучшее средство для поиска информации на сайте
Модели бизнес-процессов и информационные системы Разработка программного обеспечения
из "Реинжиниринг бизнеса - Реинжиниринг организаций и информационные технологии "
Методики, которые можно использовать в объектно-ориентированном инжиниринге бизнеса, подобны методикам объектно-ориентированной разработки программного обеспечения. Действительно, оба процесса хотя и различаются по своему назначению, имеют общую основу - объектно-ориентированные методики построения сложных систем. Эти методики конструируются так, что они обеспечивают поддержку работ по реинжинирингу бизнеса. Они тесно взаимосвязаны, поскольку характер бизнес-процессов определяет требования к информационной системе поддержки, а сама система, как было показано выше, влияет на функционирование этих процессов. В разработке программного обеспечения объектно-ориентированные методики применяются довольно широко, поскольку они уже давно продемонстрировали свое преимущество по сравнению с другими известными методиками. Использование одних и тех же подходов для построения моделей как бизнес-системы, так и соответствующей информационной системы значительно упрощает взаимосвязи между этими моделями. [c.201]Построение информационной системы - это процесс создания моделей, описывающих различные стороны этой системы. Подобно бизнес-системе, разработка информационной системы тоже имеет своих участников (владелец процесса, участник процесса, лидер процесса, аналитик, проектировщик и др.), каждый из которых может быть или не быть ее субъектом. Участник - это некто, выдвигающий требования к информационной системе или просто по тем или иным причинам заинтересованный в ее освоении. Различные участники имеют дело с разными аспектами системы, поэтому они нуждаются в различных ее моделях. [c.202]
Для каждого типа участников необходимо создавать собственные специализированные модели. Рассмотрим участников разработки бизнес-системы и поддерживающей информационной системы. В бизнес-системе всех участников можно разделить на субъектов (например, таких, как клиенты) и ресурсы (ответственные за процессы, торговые агенты и др.). В случае разработки информационной системы типичными участниками являются пользователи, которые заказывают ее, владельцы процессов, разработчики и др. Некоторые участники бизнес-системы одновременно являются пользователями информационной системы. Поэтому существуют большие преимущества в использовании одних и тех же методик для построения моделей обеих систем. [c.202]
Ниже будут подробно описаны участники, для которых создается информационная система и ее модели, затем рассмотрены шаги, выполняемые в ходе построения этих моделей, и сами модели. Далее, в разд. 8.3 представлена простейшая объектная бизнес-модель разработки программного обеспечения. [c.202]
Наиболее важные участники разработки информационной системы поддержки - заказчики и пользователи. В контексте реинжиниринга бизнес-процессов заказчики являются одновременно владельцами бизнес-процессов, а пользователи информационной системы -участниками этих процессов. Как правило, их не интересует, как будет реализована информационная система. Для них самое важное -то, что система сможет делать и как ее использовать. Для них необходимо разработать различные сценарии использования системы Эти сценарии должны быть представлены в терминах П-модели. Субъекты в таких моделях отражают разнообразные роли, которые могут играть участники бизнес-процессов и пользователи информационной системы. [c.202]
Проектировщикам в отличие от аналитиков нужны модели, позволяющие описывать различные способы выполнения системы вплоть до создания программного кода. Объектно-ориентированные языки позволяют получить только описание классов, но не информацию о взаимодействии соответствующих классов. Следовательно, проектировщикам необходимо знать, каким образом классы взаимодействуют для реализации прецедентов. Они нуждаются в реальной объектной модели, представляющей собой некоторую абстракцию программного кода. Реальная объектная модель необходима также специалистам, которые тестируют готовые программы. В этой модели принимаются во внимание такие важные технические аспекты, как среда разработки (язык реализации, доступные вычислительные ресурсы, используемая СУБД и т.д.) и ее ограничения. Результатом проектирования приложения являются исходные тексты программ, которые образуют модель реализации системы. [c.203]
Члены команды по тестированию системы нуждаются в модели, на основе которой они могли бы провести подробные испытания и убедиться в соответствии программного продукта исходным требованиям. Основу для спецификации тестовых задач представляет собой П-модель информационной системы. Каждому возможному экземпляру прецедента будет соответствовать одна тестовая задача. В совокупности спецификации тестов образуют оттестированную модель системы . [c.203]
Каждая из рассмотренных выше моделей разрабатывается и поддерживается совокупностью объектов бизнес-системы. Их задача состоит в реализации программного обеспечения модели бизнеса рассматриваемой компании. Вследствие сложности системы эти объекты обычно объединяются в подсистемы, каждая из которых соответствует отдельной модели. Таким образом, выделяют следующие подсистемы. Сбор Требований, Анализ, Идеальное Проектирование, Реальное Проектирование, Реализация и Тестирование (рис. 8.1). [c.203]
Объектная модель бизнес-системы, которая будет описана в разд. 8.3, является упрощенной моделью разработки ПО. Она не включает указанные подсистемы, но вводит все объекты непосредственно. [c.204]
Описание прецедентов создаваемой информационной системы определяется типом системы, используемыми языком программирования и методиками, а также размерами самой компании. При этом совершенно не обязательно, что будут разработаны все модели, перечисленные в данном разделе. [c.204]
Рассмотрим этапы разработки, выполняемые при создании моделей информационной системы. [c.204]
О Сбор требований. На этом этапе собираются все предложения, идеи, пожелания и требования ваших клиентов. Список рекомендаций, собранный в результате опросов, составляет промежуточный результат работы. Далее этот список прорабатывается, и для наиболее важных его компонентов составляются спецификации, которые образуют окончательный список требований к информационной системе. [c.204]
О Реальное проектирование. Здесь разрабатывается модель, служащая базисом для реализации информационной системы. Результат -реальная объектная модель информационной системы. Реализация. На этом этапе создается программный код информационной системы. [c.204]
Выше намеренно даны одни и те же имена понятиям моделирования бизнеса и разработки программного обеспечения, которые соответствуют друг другу. Благодаря этому будет легко разобраться в типах объектов и отношений для моделей информационных систем по аналогии с моделями бизнес-систем. Чтобы отличать объекты моделей информационной системы от объектов бизнес-системы, будем в тексте давать явные указания об их принадлежности. [c.205]
Все информационные системы изменяются в течение своего жизненного цикла. Для многих систем изменения оказываются наиболее дорогостоящими составляющими жизненного цикла. Тем не менее большинство известных методов разработки программного обеспечения ориентируются на создание новых систем и уделяют недостаточное внимание вопросам их модификации и развития. [c.205]
Как правило, в начале работы над проектом требования к информационной системе полностью сформулировать не удается. По мере продвижения работы знания о системе увеличиваются. В результате программный продукт может устареть уже к моменту своего появления на свет когда первая версия информационной системы создана и используется, появляются новые требования и изменяются старые. [c.205]
В некоторых случаях предпочтительнее шаг за шагом разрабатывать информационную систему, охватывающую сначала наиболее значимые прецеденты, а затем в ходе практического использования системы и накопления определенного опыта добавлять новые прецеденты (см. разд. 8.5). [c.205]
разработка информационной системы обычно сводится к созданию очередной ее версии. С этой точки зрения новая разработка оказывается частным случаем первой версии. Следует отметить, что первая версия имеет важную особенность по сравнению с последующими именно при выполнении первой версии принимаются основополагающие решения относительно архитектуры информационной системы, которые будут поддерживаться в течение всего ее жизненного цикла. [c.205]
Вернуться к основной статье