Cтраница 1
Унаследованная система часто содержит данные и требования к приложениям, которые внедрены в основном коде этой системы. [1]
Существующие бизнес-процессы, унаследованная система и сами пользователи служат источниками для сбора информации о требованиях к новой системе. Объем собранной информации может быть настолько велик, что потребует отдельного управления. В документе о требованиях очень легко может появиться несколько тысяч страниц. [2]
Определение реализованных в коде унаследованной системы процессов столь же важно, как выяснение бизнес-правил. Сотрудники, связанные с процессами, часто забывают о бизнес-правилах, но оба эти аспекта важны для успеха всего проекта. Наблюдая за реальной работой пользователей в системе, аналитик может понять, как они будут взаимодействовать с новой системой. Новая система, заменяющая унаследованную, должна замещать только такие бизнес-функции, которые пользователи считают необходимыми для обеспечения своей деятельности. [3]
Аналитик должен также рассмотреть производительность унаследованной системы. Как долго выполняются отчеты. Как быстро реагируют пользователи при выполнении различных задач. Новая система должна превысить быстродействие старой. Важно узнать у пользователей, где требуется большая производительность и где она менее значима. Следует ранжировать пожелания о производительности и выяснить наиболее часто выполняемые действия пользователя - тогда можно сделать новую систему более эффективной. [4]
Конечно, нужно прочитать всю документации по унаследованной системе и любую дру1ую пользовательскую документацию. Эти сведения часто указывают на требования пользователей, не упомянутые в других местах. [5]
Проведя все опросы пользователей, сеансы JAD и обзоры унаследованной системы, аналитик остается один на один с огромной папкой заметок. Заметки могут: быть структурированы по функциональным областям, но часто требования охватывают несколько отдельных областей и не получается чистой иерархической структуры, отражающей взаимосвязь требований и областей деятельности организации. Аналитик должен пытаться расширить функциональную иерархию, полученную на фазе стратегии, чтобы на фазе анализа полностью ее закончить. [6]
Аналитики должны вместе с пользователями проследить реальные транзакции в унаследованной системе. Это позволит увидеть, какие части старой системы используются и каким образом. [7]
В этом разделе описываются операции и выполняющие их утилиты. Создание ERD унаследованной системы в основном автоматизировано средствами Oracle Designer. Вместо ручного выполнения операций, обычно очень трудоемкого процесса, Oracle Designer делает почти всю работу и гарантирует успешное создание объектов. [8]
Частью проводимого анализа становится подготовка предварительной программной доски хранения для всех прототипов пересмотренного приложения. Поскольку существует рабочая база данных унаследованной системы, прототип новой системы сопоставляется с рабочей базой данных с использованием реальных данных, обрабатываемых организацией. [9]
Бизнес-требования внедрены в код старой системы. Аналитику нужно либо самостоятельно рас-смотрегь ( прокрутить) код унаследованной системы, либо совместно с ее разработчиками выявить внедренные в ее код пользовательские требования. [10]
В главе 9 подробно анализируются необходимые для сбора информации требования к системе. Нужно извлечь соответствующие системные требования из всех опросов и данных унаследованной системы, которые использовались в процессе сбора. [11]
Разбор кода программы - трудная задача, даже если очень хорошо знать старое приложение и прекрасно разбираться в используемом языке программирования. Такую работу рекомендуется проводить совместно с разработчиками старой системы или программистами сопровождения унаследованной системы. Если тексты кодов не согласовывались с работающими программами и не были хорошо документированы или нет связи с разработчиками старой системы, лучше вообще отказаться от разбора кода программ. [12]
Короче, нужно назвать одиночное, неиспользуемое и определяемое пользователем свойство - Legacy Status. При публикации этого расширения свойство появится в диалоговом окне Properties модуля репозитория, который применен для назначения статуса каждому отчету унаследованной системы. Для облегчения ввода данных допустимо использование RON или Matrix Diagrammer либо собственной утилиты. [13]
Например, существует ( если повезет) только один набор исходных текстов для каждой программы и ( если очень повезет) один набор документации для этой же программы. Следовательно, обзор унаследованной системы должен проводиться высококвалифицированными и ответственными сотрудниками. [14]
Для создания ERD старой системы нужно фиксировать разработку только тех таблиц, которые необходимы для представлений, моментальных снимков, триггеров и индексов. В качестве альтернативы можно зафиксировать разработку всех таблиц и установить свойство Complete ( завершено) на Table Implementation в значение No, что отменит генерацию DDL для данной таблицы. Это даст прекрасную документацию по унаследованной системе, и, если потребуется включить таблицу позже, нужно будет установить свойство Complete в значение Yes, что сделает таблицу доступной для использования. [15]