Реинжиниринг
Методическое пособие - Разное
Другие методички по предмету Разное
?овней подсистем. Рис6.3. содержит пример верхнего уровня из отношения состоит из выделены подсистемы. Выявление объектов проводится во время реинжиниринга. При этом определяется на сколько будет глубоким проект, длительность его разработки, как будет изменяться сам бизнес.
19-22.06.08 защита ГАК
Построение информационной системы в рамках реинжиниринга.
1.Наряду с проведением реинжиниринга на предприятии, сразу же определяют его влияние на будущую информационную систему.
Разработка ИС базируется на разработке ПО это бизнес-процесс, результатом которого является интеллектуальный труд. Одним из прецедентов является разработка ПО. Входом этого прецедента являются требования к программному продукту, а выходом новая версия этого продукта. Разработка ИС это процесс создания моделей, описывающих различные стороны этой системы. Подробно бизнес-системе, разработка ИС тоже имеет своих участников: владелец процесса, участник процесса лидер процесса, аналитик, проектировщик и другие. Каждый из них может быть или не быть субъектом. Участник это некто, выдвигающий требования к ИС или просто заинтересованный в ней. Наиболее важными участниками являются заказчики и пользователи. В контексте реинжиниринга бизнес-процессов, заказчики являются одновременно и владельцами бизнес-процесса. Пользователи системы участники этих процессов. Как правило последних не интересует как будет реализована информационная система. Для них важно что она им предоставляет. Эти сценарии и закладываются в П-модели системы. Субъекты в этих моделях отражают разные роли, которые могут играть участники бизнес-процессов и пользователи ИС. Системным аналитикам необходима модель на основе которой они могут создать гибкие, легко модифицируемые системы. Модель не должна иметь высокую детализацию. В ней важно выделить независимые функциональные группы в системе такие, чтобы внесение изменений в приложения не воздействовало на всю систему (инженерия предметной области). Для того, чтобы удовлетворять этому требованию, целесообразно разработать идеальные модели ИС, абстрагирующиеся от особенностей конкретной реализации.
Проектировщики. Им нужна модель, позволяющая описывать различные способы выполнения системы вплоть до создания программного кода. Другие члены команды и члены по тестированию системы нуждаются в модели, которая проверила бы реальность программного продукта (модель контрольного примера) при этом каждому прецеденту соответствует одна тестовая задача. Этапы разработки моделей ИС представлены на рисунке 8.1. В соответствии с этим рисунком собираются:
1. все предложения, идеи, пожелания и требования клиентов.
2.анализ требований. На этом этапе производится анализ полноты и не противоречивости спецификации требований. На этом этапе строится П-модель ИС, а так же интерфейса пользователя.
3.реальное проектирование. Разрабатывается модель, служащая базисом для реализации ИС.
4. реализация. На этом этапе создается ПО.
5.тестирование. Проверяется соответствие ИС к предъявляемым к ней требованиям.
В П-модели ИС, субъекты представляют роли, которые могут исполнять пользователи системы, а прецеденты те действия, которые они могут производить над ней. Каждый прецедент это завершенный поток событий в системе, рассматривают с точки зрения пользователя.
Прецеденты в ИС играют две важные роли:
1.Прецеденты естественным образом описывают функциональные требования к ИС. П-модель определяет систему через множество прецедентов. Окружение информационной системы определяется описанием различных субъектов, которые используют эту систему так, как это описано в прецедентах. П-модель дополняется О-моделями. П-модель внешни взгляд на ИС. О-модель взгляд изнутри.
2.Прецеденты структурируют каждую объектную модель. При этом полезно структурировать О-модель таким образом, чтобы каждая из них представляла некоторый отдельный аспект ее использования. Аспект соответствует одному прецеденту ИС. И его описание включает только те объекты, которые участвуют в этом прецеденте. Идеальная модель использует объекты 3 типов: интерфейсные, управляющие и объекты-сущности. Объекты-сущности мало изменяемые сущности живущие дольше, чем экземпляры прецедентов, в которых они участвуют. Используются для представления атрибутов, отношений и поведения тех или иных явлений, событий, персонала. Управляющие объекты используются для описания поведения системы, задаваемого прецедентами. Обычно они управляют другими объектами и выполняют роль координаторов модели. Объекты бизнес системы представлены в рис 8.2. Порядок сбора требования описан в 8.3. Анализ требований представлен на рис 8.4.