Фаза - предварительный анализ
Cтраница 2
Из законченных частей фазы предварительного анализа должно быть ясно, какова цель этой фазы, т.е. нужен подробный план, гарантирующий завершение фазы анализа, когда сформированы и выполнены все требования к этой фазе. [16]
Как отмечалось при обсуждении фазы предварительного анализа ( см. главу 5), для небольших проектов такая фаза не столь важна. [17]
 |
Инструменты разработки и обслуживания для фазы предварительного анализа. [18] |
Основной завершенной частью на фазе предварительного анализа является аналитический план. [19]
Аналитический план, разработанный на фазе предварительного анализа, должен описывать всю фазу анализа на основе информации, оформленной к моменту завершения аналитического документа. [20]
Как уже говорилось, на фазе предварительного анализа может потребоваться список элементов и процессов, которые отражены на диаграммах фазы стратегии. [21]
Для небольших проектов может не потребоваться вся фаза предварительного анализа, если документ по стратегии обеспечивает достаточно подробные сведения для перехода непосредственно к фазе анализа. Однако для проектов среднего размера все же рекомендуется транзитная фаза предварительного анализа, потому что на пути формирования системы создаются контрольные точки. [22]
 |
Инструменты разработки и обслуживания для фазы предварительного анализа. [23] |
В этой главе рассматривается создание завершенных частей фазы предварительного анализа с помощью двух утилит Oracle Designer: Repository Object Navigator и Repository Reports. Эти утилиты полезны и на других фазах CADM, поддерживаемых в Oracle Designer. Глава 27 подробно описывает утилиту администрирования репозитория ( Repository Administration Utility), которую можно применять для отслеживания требовании к системе в Oracle Designer, но в данной главе мы обсудим и пользовательские расширения, создаваемые в этом инструменте, которые помогут в работе на фазе предварительного анализа. [24]
Как отмечалось выше, большинство аналитиков пропускают фазу предварительного анализа даже для больших проектов. Однако статистика реализации множества бизнес-проектов в 60 - 70 - х годах показывает: приблизительно 80 % общего числа проектов закончилось неудачей. [25]
Любые изменения, которые влияют на работу, проделанную на фазе предварительного анализа, нужно реализовывать так же, как и на фазе предварительного проектирования. [26]
Далее мы рекомендуем применять нефункционирующие доски хранения прототипов, поставляемые как законченные части фазы предварительного анализа. Однако нужно создать и предварительные прототипы на основе анализа модулей, поскольку сбор информации продолжится. [27]
Сначала следует применить пользовательское расширение ( см. главу 27) для создания ассоциативного элемента, который связывает требования с модулями, как это делалось при связывании требований с функциями на фазе предварительного анализа. Затем необходимо назначить каждое требование одному или нескольким модулям в RON или Matrix Diagrammer. Разумеется, можно написать процедуру API, которая последовательно просмотрит каждую функцию и определит связанные с ней требования. Далее производится поиск модуля или модулей, основанных на данной функции ( ассоциативный узел модуля Usage: Implementing Business Function), и назначение модулям тех же самых требований. [28]
Для небольших проектов может не потребоваться вся фаза предварительного анализа, если документ по стратегии обеспечивает достаточно подробные сведения для перехода непосредственно к фазе анализа. Однако для проектов среднего размера все же рекомендуется транзитная фаза предварительного анализа, потому что на пути формирования системы создаются контрольные точки. [29]
Способ оценки аналитического плана подобен оценке правильности ERD. Чтобы проверить мнение о правильности ERD нужно найти пример данных, которыми не сможет управлять предложенная модель. При оценке фазы предварительного анализа полезно попросить пользователей попытаться найти такие требования, которые не будут собраны в предлагаемом процессе анализа данных. [30]
Страницы: 1 2 3