Cтраница 1
Фаза анализа не предназначена для того, чтобы выяснять все правила преобразования старых данных и приспосабливать их для нужд новой системы. На этой фазе составляется контрольный список старых элементов данных, которые нужно переносить. [1]
![]() |
Стандартный сетевой график работ группы обслуживания. [2] |
Фаза анализа осущ фаза, исследований. [3]
Фаза анализа логически разделяется на две части: сбор информации и анализ требований. На этапе сбора информации и получения требований от пользователей применяются собеседования, анкетные опросы, электронные доски объявлений и рассылочные списки, совместная разработка приложений во время сеансов JAD, а также исследование старой системы, аудит отчетов и знакомство с системной и пользовательской документацией. [4]
Фаза анализа состоит из двух этапов: сбор информации и анализ требований. Анализ начинается, как только накопится некоторая информация, и для этого не нужно ждать, пока она будет собрана вся. Вместе с накоплением информации ее нужно анализировать, а после получения всей информации производится заключительный анализ данных. К концу фазы анализа нужно выявить и разрешить все противоречия, а затем сформулировать согласованные требования к новой системе. [5]
Поэтому фаза анализа больше нацелена на пользователей, а не на саму систему. В этот момент делается попытка формализации требований пользователей и выявляются методы работы организации. Позже эти элементы могут оказаться вне рамок проекта или бюджета, но в данный момент нет причин отвергать любые требования пользователей, ведь единственной целью является знакомство с этими требованиями. [6]
Вторая фаза анализа предметной области состоит в выборе информационных объектов и заданий необходимых свойств для каждого из них; выявлении связи между объектами; определении ограничений, накладываемых на информационные объекты, типы связей между ними, характеристики информационных блоков. [7]
![]() |
Элементы фазы анализа и соответствующие им элементы фазы разработки, создаваемые в DDT. [8] |
Модель фазы анализа может содержать конструкции, которые нельзя взаимно однозначно перенести в реляционную базу данных, поэтому DDT устраняет проблемы подобного рода. Обычно такие взаимосвязи преобразуются в связи один-ко-многим между двумя первоначальными таблицами и новой перекрестной таблицей. [9]
Целью фазы анализа является сбор всех пользовательских спецификаций проекта и полное завершение детализации рассматриваемых в проекте бизнес-процессов. [10]
На фазе анализа нужно сохранить определения для отчетов старой системы и назначить им приоритеты. [11]
На фазе анализа основное внимание уделяется пользователю, а также новой и старой системам. Пользователи обладают бесценными знаниями о старой системе и о том, как должна работать новая система. Эти данные должны быть выявлены у пользователей, после чего фокус смещается на анализ собранных данных. Полученная информация организуется в форме ERD и функциональной иерархии, но сохраняются прямые ссылки на пользователей, предоставивших сведения о новой системе. Система не сможет быть построена корректно без перекрестной проверки, которая и обеспечивается документом о требованиях. [12]
На фазе анализа нужно обратить внимание и на флажок Elementary. Он устанавливается для функций, представляющих логический модуль работы, которая должна быть полностью завершена, чтобы быть полезной для деятельности организации. Application Design Transformer использует это значение при определении функций, преобразующихся в модули на фазе разработки. Нужно точно вводить значение, если эта утилита будет использована на последующих фазах. [13]
![]() |
Элементы Function Hierarchy Diagrammer и элементы репозитория. [14] |
На фазе анализа для функций на уровне объекта создается использование CRUD ( по крайней мере, CUD), т.е. должны быть определены использования данных объекта для каждой функции в системе. Следует проверить каждую функцию на наличие некоторого способа ввода всех данных в объекты через существующие функции или через функции или процессы вне анализируемой системы. Должна быть гарантия, что для каждого объекта существуют характеристики создания, изменения и удаления, либо должны быть веские причины для их отсутствия. Например, можно не иметь характеристик создания для объекта, представляющего данные во внешней системе, если предполагается не вставка данных в этот объект, а только извлечение. [15]