Cтраница 1
Аудит отчетов предполагает обзор и анализ всех отчетов, созданных в старой системе. Аналитики должны заранее запланировать аудит отчетов, чтобы определить, будет ли конкретный отчет сохранен, удален или изменен по сравнению с первоначальным состоянием. [1]
В аудите отчета должны принимать участие несколько пользователей. В аудите нужно задействовать представителей различных категорий пользователей. Разработчик разделяет пользователей на группы, для которых предназначен данный отчет. [2]
Как и для аудита отчетов, собранные заметки о бизнес-целях и факторах, критических для успеха, могут быть возвращены обратно руководству организации для подписания на всех соответствующих уровнях. [3]
Полностью определить атрибуты модели, тщательно исследуя все требования пользователя и реализованные в старой системе отчеты, как при аудите отчетов. Важными источниками для атрибутов станут моментальные снимки экранов новой и старой системы, старые и новые отчеты. В определении атрибутов должны участвовать и пользователи. Если ERD не может поддерживать генерацию отчета, требуется провести дополнительную работу. [4]
Аудит отчетов предполагает обзор и анализ всех отчетов, созданных в старой системе. Аналитики должны заранее запланировать аудит отчетов, чтобы определить, будет ли конкретный отчет сохранен, удален или изменен по сравнению с первоначальным состоянием. [5]
Требуется идентифицировать все возможные источники информации, включая полный просмотр кодов при аудите отчетов, опросы пользователей, сеансы JAD, исследование системной и пользовательской документации, а также любые другие источники информации. [6]
При сборе информации на фазе анализа необходимо объединить собранные сведения и создать полноценный список требований к системе. Информация поступает из различных источников: заметки об опросе, предварительная диаграмма ERD, функциональная иерархия, аудит отчетов и требования, извлеченные из старой системы. В этой массе сведений нужно выявить согласованную модель данных и функциональную архитектуру, поддерживающую требования к системе. Традиционный метод CASE явным образом не рассматривает документ о требованиях, что может привести к неудовлетворению пользователей новой системой или полному краху всего проекта. Решением проблемы может стать привлечение пользователей к участию в разработке документа о требованиях, который должен содержать описание потоков процессов, аналитическую ERD и функциональную иерархию. Этот документ является главной законченной частью фазы анализа. [7]
Их следует планировать по темам - например, аудит модели данных, анализ высказанных замечаний, результаты анализа старых данных, аудит старых отчетов. [8]
Фаза анализа логически разделяется на две части: сбор информации и анализ требований. На этапе сбора информации и получения требований от пользователей применяются собеседования, анкетные опросы, электронные доски объявлений и рассылочные списки, совместная разработка приложений во время сеансов JAD, а также исследование старой системы, аудит отчетов и знакомство с системной и пользовательской документацией. [9]
На фазе анализа нужно сохранить определения для отчетов старой системы и назначить им приоритеты. Модуль - это законченное приложение, обычно форма или файл отчета, который действует как отдельная часть системы. В отчетах старой системы модулем, возможно, будет свойство Language в Oracle Reports и Module. Свойство legacy Status ( статус унаследованности) служит для назначения приоритетного уровня во время аудита существующих отчетов. [10]