Фаза - анализ
Cтраница 3
До перехода на фазу анализа должен существовать аналитический план, определяющий этапы работ и завершенные части проекта. Само слово анализ определено не четко, и различные аналитики по-разному трактуют эту фазу. Разработчик должен включить в план определение границ анализа. [31]
Главное внимание на фазе анализа уделяется созданию документа о требованиях к системе. Однако важны и другие законченные части, к которым можно отнести общий аналитический документ, заканчиваемый на этой фазе разработки. Аналитический документ состоит из следующих частей: аналитическая ERD, схема потоков процессов ( логическая), документ о требованиях и оценка фазы анализа. [32]
На этане между фазами анализа и разработки планируется оставшаяся часть проекта. Только после фазы анализа разработчик точно узнает, что должна делать создаваемая система. Переход от фазы анализа к фазе разработки осуществляется в несколько этапов. Некоторые полагают, что эти этапы принадлежат фазе анализа; другие энергично утверждают, что они находятся в фазе разработки. [33]
В BPR существенно удлиняется фаза анализа проекта. Парадокс заключается в том, что при успешной реализации BPR общая стоимость системы может остаться прежней или даже уменьшиться и поэтому гораздо проще разработать и реализовать новый процесс, чем идти по проторенной дорожке. [34]
Первый вопрос при оценке фазы анализа связан с полнотой набора требований, а ответ будет всегда отрицательным, поскольку обязательно что-нибудь оказывается пропущено. Если отсортировать требования по детализации функций и показать их пользователям, всегда можно найти что-то новое. Собственные разработчики организации тоже должны принять участие в оценке требований к новой системе. Обычно они более осведомлены о реальных целях на уровне отдельных деталей, чем большинство пользователей. Кроме того, разработчики должны проверить, специфицированы ли требования к производительности системы. [35]
Последний вопрос в оценке фазы анализа - корректна ли функциональная иерархия. Назначение функциональной иерархии состоит в отображении бизнес-процессов и проверке присутствия всех требований к системе в плане реализации. Функциональная иерархия используется в основном для организационных целей. Если представлены все основные бизнес-функции, все требования отображены хотя бы на одну функцию и каждая функция содержит, по крайней мере, одно связанное с ней требование к системе, то оценку фазы анализа можно считать законченной. [36]
Подход RAD-CADM намного сокращает фазу анализа разработки системы. Вместо этой фазы, для определения требований используется повторяющийся процесс разработки. При этом предполагается, что стоимость разработки достаточно низка, и построение значительной части системы обойдется вдвое-втрое дешевле, чем выполнение всей фазы анализа. Таким образом, вместо выполнения полного анализа, RAD-CADM предполагает построение серии макетов системы. [37]
При сборе информации на фазе анализа необходимо объединить собранные сведения и создать полноценный список требований к системе. Информация поступает из различных источников: заметки об опросе, предварительная диаграмма ERD, функциональная иерархия, аудит отчетов и требования, извлеченные из старой системы. В этой массе сведений нужно выявить согласованную модель данных и функциональную архитектуру, поддерживающую требования к системе. Традиционный метод CASE явным образом не рассматривает документ о требованиях, что может привести к неудовлетворению пользователей новой системой или полному краху всего проекта. Решением проблемы может стать привлечение пользователей к участию в разработке документа о требованиях, который должен содержать описание потоков процессов, аналитическую ERD и функциональную иерархию. Этот документ является главной законченной частью фазы анализа. [38]
Этап формирования требований на фазе анализа объединяет все собранные от пользователей материалы. На основании этих сведений вырабатываются соответствующие требования к системе. В рамках этого процесса производится определение как старой системы и потенциальных изменений в ней, так и новых потоков процессов, относящихся к разрабатываемой системе. Цель состоит в создании согласованных формулировок для всех требований к новой системе. [39]
Здесь также специфицируют законченные части фазы анализа. [40]
Осадок, полученный в этой фазе анализа, может состоять из не изменившихся сульфатов или из веществ, не разложившихся при обработке серной кислотой. [41]
 |
Комплексы задач и модели фазы анализа. [42] |
Выходная информация фазы учета используется фазой анализа, на вход моделей которой поступает также выходная информация фазы планирования как эталон состояния производства. [43]
 |
Операции процесса внедрения и инструментальные средства Oracle Designer. [44] |
Отчеты, в которых фигурируют элементы фазы анализа, не слишком важны для пользовательской документации или для документации справочной службы. Однако можно представить группы текущих отчетов в качестве системной документации тем проектировщикам и разработчикам, которые не имеют доступа к репозиторию. Единственным недостатком таких отчетов является то, что они устаревают сразу же после внесения в репозиторий каких-либо изменений. Самой лучшей документацией для системы всегда является сам репозиторий, если, конечно, он обслуживается на должном уровне. Если отчеты крайне важны, можно создать отчет Report Builder, запрашивающий и отображающий текущее содержимое репозитория. [45]
Страницы: 1 2 3 4