Отчёт об обследовании

Здесь я расскажу, как пишется отчёт об обследовании, на какие моменты при этом следует обратить внимание.

Отчёт - документ, который содержит систематизированные данные о проведённой работе, описывает состояние научно-технической проблемы, процесс, результаты научно-технического исследования. Отчёт об обследовании содержит результаты работы аналитиков по обследованию объекта автоматизации.

На практике чаще всего отчёт оформляется по завершении обследования. Однако в ряде случаев, если это предусмотрено планом обследования, могут составляться промежуточные отчёты. Правила их оформления те же, что и для заключительного.

Стандарты и правила

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

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

В общем случае я не рекомендую уходить далеко от ГОСТа. Во-первых, всегда сложнее писать документ с вольной структурой. Во-вторых, при использовании ГОСТа легче согласовывать структуру отчёта и сам документ между всеми заинтересованными сторонами.

Общие требования изложены в ГОСТ 7.32-2017 «Отчёт о научно-исследовательской работе». Там же описаны требования к оформлению (формат страницы, отступы, шрифты и т.п.).

Требования к основной части изложены в Приложении 1 к РД 50-34.698-90 «Автоматизированная система. Требования к содержанию документов». Требования к основной части являются рекомендуемыми. От них можно отступать, не нарушая общих требований. В частности, можно менять состав разделов в зависимости от цели и задач обследования. 

Структура отчёта

Согласно ГОСТ 7.32, отчёт должен иметь следующую структуру:

• титульный лист (обязательно);

• список исполнителей (обязательно);

• реферат или аннотация по ГОСТ 7.9-95 (обязательно);

• содержание (обязательно);

• термины и определения;

• перечень сокращений и обозначений;

• введение или общие сведения (обязательно);

• основная часть отчета (обязательно);

• заключение (обязательно);

• список использованных источников;

• приложения.

На деле, список исполнителей указывается редко, особенно, если обследование проводит подрядная организация.

Содержание может быть опущено, если отчёт содержит менее 10 страниц.

Аннотацию по ГОСТ 7.9-95 оформляют нехотя и очень редко. Придираются к ней только госзаказчики.

Введение (чаще этот раздел называют «Общие сведения») имеет несколько подразделов:

• наименование объекта обследования (автоматизации);

• цель обследования;

• предмет и границы обследования;

• задачи обследования;

• методы обследования;

• источники информации.

Существует некоторая путаница в голове аналитика, когда он видит термины «объект обследования» и «предмет обследования». На деле объектом обследования является некоторая организация, её подразделение или группа лиц. При указании названия объекта обследования принято указывать полное наименование организации, краткое наименование и адрес (юридический и/или фактический). Фактический адрес – адрес проведения обследования.

Предмет обследования – некоторая деятельность, процесс или действующая система. Я чаще указываю в качестве предмета обследования некую деятельность, осуществляемую с использованием действующей информационной системы, если речь идёт о сопровождении или развитии этой системы. Если планируется создание новой системы, то предметом обследования является деятельность, которую предполагается автоматизировать.

Цель, задачи и методы обследования приходят из плана обследования.

Перечисление источников информации должно охватить интервьюированных лиц, пользователей, за работой которых велось наблюдение, нормативную документацию, техническую и эксплуатационную документацию, примеры данных, артефакты действующей системы.

Структура основной части отчёта определяется в Приложении 1 к РД 50-34.698-90:

• характеристика объекта и результатов его функционирования;

• описание существующей информационной системы;

• описание недостатков существующей информационной системы;

• обоснование необходимости совершенствования информационной системы объекта;

• цели, критерии и ограничения создания ИС;

• функции и задачи создаваемой ИС;

• ожидаемые результаты создания ИС;

• выводы и предложения (вместо заключения).

Таким образом, заключение в отчёте об обследовании может не указываться. Вместо него приводятся выводы и предложения.

Ниже я расскажу о каждом разделе основной части подробнее.

Характеристика объекта автоматизации

В характеристике объекта автоматизации обычно указываются следующие сведения:

• общие сведения об объекте обследования/автоматизации;

• описание организационной структуры;

• описание основных бизнес-функций каждой организационной единицы объекта, с указанием количественных качественных характеристик;

• описание информационных потоков внутри объекта;

• описание внешних взаимодействий объекта;

• описание бизнес-процессов.

Общие сведения содержат историю развития организации, её текущее состояние, тенденции, показывающие актуальность проблемы, рассматриваемой в рамках обследования.

Описание организационной структуры содержит перечисление подразделений организации – объекта обследования и описание их взаимодействия.

Основные бизнес-функции задаются в привязке к подразделениям, выполняющим эти функции.

Тут важно отметить, что при описании бизнес-функций не следует опускаться до уровня их реализации в действующей или перспективной системе. Этому посвящены специальные разделы отчёта. Описывая объект обследования, мы говорим о бизнес-целях, бизнес-задачах и бизнес-процессах. Информационные системы – только инструмент или способ реализации этих целей, задач и процессов. Инструменты и способы реализации могут быть разными, и не о них идёт речь при описании предметной области.

Описание внешних и внутренних информационных потоков тоже должно даваться с точки зрения проблемы, а не её решения. 

Описание существующей информационной системы

Объяснив, что из себя представляет объект и предмет обследования, и описав предметную область, можно перейти к описанию текущей реализации системы (если она есть, конечно).

Начать нужно с описания текущего состояния IT-инфраструктуры объекта автоматизации. Конечно, следует ограничиться только той частью инфраструктуры, которая имеет влияние на действующую информационную систему. Обратить внимание нужно на узлы, где развёрнута сама система, используемые ею хранилища данных, внешние системы, рабочие станции пользователей. Описание должно содержать параметры аппаратного и программного обеспечения, обеспечивающего функционирование системы. Не следует забывать о требуемых лицензиях.

Далее описываются цели и задачи информационной системы, её основные функции. При описании целей и функций информационной системы следует связать их с бизнес-целями и бизнес-функциями объекта автоматизации.

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

Следует свести в единый подраздел описание структуры и состава данных, используемых в системе. В этом описании нужно уделить внимание:

• нормативной и справочной информации;

• входным данным, поступающим из внешних источников (с указанием источника и регламента поступления данных), или загружаемых из файлов (с указанием форматов файлов и места их размещения);

• входящим данным, задаваемым пользователями;

• результатам работы системы;

• данным, предоставляемым пользователю или внешним системам, либо экспортируемым в файлы (с указанием формата файлов и места их хранения);

• данным, хранимым в постоянных и временных хранилищах (кэш, база данных и т.п., с указанием времени хранения).

Если возможно, для каждого типа данных, передаваемых по каналам связи, следует указать максимальный и средний объём данных. Для хранимых данных следует указать их фактический объём и прирост за единицу времени (с учётом объёма добавляемой и удаляемой информации).

Далее нужно описать структуру постоянного хранилища данных (как правило – базы данных).

Затем описывается структура исходного кода системы.

Завершают описание системы разделы, описывающие пользовательский интерфейс и программные интерфейсы взаимодействия с внешними системами (API). 

Описание недостатков существующей системы

Наверное, этот раздел самый важный с точки зрения фактического состояния предмета обследования. Здесь фактически описываются характеристики качества действующей системы. Причём описание должно соответствовать двум чётким условиям:

• каждый указанный здесь пункт должен подтверждаться документальными фактами;

• каждый факт, подтверждающий недостаток качества системы, должен быть подтверждаемым, т.е. нужно дать возможность независимому эксперту воспроизвести ситуацию, описываемую в отчёте.

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

Я исхожу из показателей качества, перечисленных в ГОСТ Р ИСО/МЭК 9126-93. По сути, перечисленные в стандарте характеристики и показатели качества используются как план описания недостатков действующей системы.

Следует обратить внимание на несколько моментов.

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

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

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

Обоснование необходимости разработки или модификации системы

Если обследование проводилось для того, чтобы принять решение, что делать дальше с имеющимся IT-активом, то данный раздел – самое подходящее место, чтобы дать свои рекомендации. Решений может быть три:

• действующая система не имеет критических недостатков и может эксплуатироваться в текущем виде или с незначительными доработками (далее перечисляются рекомендуемые доработки, опираясь на перечень недостатков системы);

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

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

И вот теперь следует описать основные требования к модифицируемой или создаваемой системе. Делается это стандартно по следующему плану:

1. Цели создания или модификации системы.

2. Критерии и ограничения создаваемой системы.

3. Функции и задачи создаваемой системы.

4. Ожидаемые результаты создания системы.

Выводы и предложения

Этот раздел используется в отчёте об обследовании вместо заключения. Он содержит итог всего описанного выше.

Важность данного раздела заключается в том, что лица, принимающие решения о проведении и финансировании работ, о выделении под них организационных и технических ресурсов, не будут смотреть весь отчёт. Они никогда отчёты не смотрят. Чаще могут отдать отчёт на независимую экспертизу, но самостоятельно читать отчёт они не могут в силу иной компетенции и элементарной занятости. А потому итоговые выводы – единственный раздел, которому они уделят своё внимание.

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

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

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

Согласование отчёта

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

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