Следует тщательно изучать, какие задачи решают "старые" системы, какое оборудование и программное обеспечение они имеют, какой персонал работает в информационном отделе; существуют ли базы данных, какова их структура и какими методами формируются отчеты о результатах — все это — важнейшие вопросы.

Важно выяснить: применяется ли кодирование информации и какие уровни кодов при этом используются (местные, государственные, международные); существующий регламент обработки данных, кого и почему он не устраивает, бывают ли практические задержки данных и отчетов, причины задержки; есть ли документация на старую систему. Такой перечень целей следует иметь как памятку в личном дневнике исследователя системы.

Рис. 2.1. Этапы проведения системного анализа информационных систем

Второй этап системного анализа — это сложнейший и ответственный шаг в массу метаинформации, т. е. "данных о данных". Главными ориентирами в организации метаинформации являются объекты (документы, диаграммы, аналитические тексты и записки, экономические показатели, совокупности), а также процессы создания объектов, процессы их передачи, обработки, хранения.

Для выполнения третьего этапа системного анализа (анализ требований системы) исследователь должен иметь определенные знания типовых методов решения основных управленческих задач (учетных, аналитических, плановых, оперативных). Все перечисленное является составной частью специальных знаний системного аналитика. Поэтому системный аналитик должен проследить все ветви комплекса требований в беседах с конечными пользователями, а затем сделать аналитические системные выводы. Эти требования есть и поддерживаются существующей информационной системой, а это должно стать функциональным требованием к новой улучшенной системе.

Третий этап системного анализа — определение того, что должно быть в новой АС. Это методологический этап синтеза требований к новой системе, которые вытекают из первых двух шагов анализа, а также из специальных знаний и средств системных аналитиков. Специалисты по системному анализу знают, что одной из коварных ловушек в их работе является возможность спутать анализ существующей системы с тем, что должно быть. Поэтому второй и третий этапы системного анализа четко разделены. Об этом важно помнить для того, чтобы не ошибиться в оценках основы, на которой строится новая система. В системотехнической методологии анализ существующего отделяется от анализа черт будущего, чтобы не воспринять желаемое за действительное.

Четвертый, итоговый этап системного анализа (документирование требований к новой системе) должен обобщить имеющиеся аналитические материалы и создать документированное отображение функциональных требований к новой АС. Документ "Требования к системе", или "Функциональные требования", является основой дальнейшей работы специалистов информационного отдела для создания детального проекта новой системы, т. е. для создания спецификаций всех ее элементов, программ, инструкций.

Таким образом, этап системного анализа отвечает на вопрос, что должна иметь информационная система для удовлетворения требований пользователей, а этап системного проектирования отвечает на вопрос, как конкретно осуществить такую АС.

Во многих аспектах системный анализ является наиболее трудной частью процесса создания системы. Проблемы, с которыми сталкивается системный аналитик, взаимосвязаны, что является одной из главных причин сложности их решения:

1) аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика;

2) заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является выполнимым, а что — нет;

3) аналитик сталкивается с чрезмерным количеством подробных сведений о предметной области и о новой системе;

4) спецификация системы из-за объема и технических терминов непонятна для заказчика;

5) в случае понятности спецификации для заказчика, она будет недостаточной для разработчиков, создающих систему.

Итак, на данном этапе эволюционного развития ситуация в области проектирования АС выглядит следующим образом:

• имеется субъект — потенциальный заказчик, испытывающий дискомфорт, для преодоления которого необходимо решить ряд проблем, и поэтому этот субъект является источником деятельности;

• имеется перечень потребностей, которые необходимо удовлетворить;

• известны прототипы программных средств с механизмами, которые в совокупности могли бы удовлетворить имеющиеся потребности, но эти механизмы не связаны в единое целое так, чтобы удовлетворить все имеющиеся потребности.

Теперь необходимо сформулировать цели и определить ограничения на реализацию программного продукта.