Разработка технического проекта

Введение

Цель нашей работы — дать вам набор шаблонов и фраз для каждого из разделов Технического задания (ТЗ), которые вы сможете использовать и развивать в своих реальных проектах. Детальное знание предмета приходит только после обследования деятельности компании, которое может занять месяц-полтора, и только после этого можно писать полноценное ТЗ.

Раздел 1. Специфические требования к системе и ее компонентам

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

Требования к защите информации от несанкционированного доступа
Это часть более широкой области информационной безопасности. В ТЗ мы определяем разграничения, которые будут существовать в системе, и механизмы для их реализации. В некоторых системах разграничений нет, и все пользователи имеют равный доступ. Если требования по данному разделу не формулируются, необходимо явно указать: «Требования не задаются», чтобы зафиксировать этот факт. Описываемое разграничение касается как доступа к данным, так и возможностей по работе с ними.

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

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

Требования к патентной чистоте
Применительно к информационным системам это обычно означает требование создать систему, для эксплуатации которой не потребуется дополнительная закупка лицензий. Если этот пункт не прописать, впоследствии разработчик может потребовать дополнительную плату за лицензии, например, на систему управления базами данных (СУБД), что может оказаться дорогим сюрпризом. Несмотря на кажущуюся отстраненность от ИТ, этот пункт крайне важен.

Требования по стандартизации и унификации
Эти требования базируются на опыте разработки и направлены на однотипность решений.
• Единообразие интерфейса: Одинаковые действия пользователя должны приводить к одинаковым результатам. Если в одной подсистеме щелчок мыши по объекту раскрывает его, а в другой — удаляет, работать с системой будет крайне неудобно.
• Система документации: На выходе должна формироваться не разрозненная документация, а взаимоувязанный комплект документов, характеризующий автоматизируемую деятельность.

Раздел 2. Детализация требований по подсистемам и задачам
После описания общих требований мы переходим к детализации по задачам и подсистемам. Описание ведется в том порядке, который вытекает из разбиения системы на части. Источниками информации здесь служат:
• Диаграммы IDEF0 низкого уровня: показывают, какие функции мы возлагаем на конкретные подсистемы.
• Диаграммы IDEF3: дают информацию о том, как эти действия будут выполняться, какие операции должна поддерживать подсистема (просмотр, редактирование, добавление элементов).
• Диаграммы DFD и ERD: описывают структуры и потоки информации, с которыми работает подсистема.
Таким образом нужно пройти по всем выделенным подсистемам, детально описав их будущее функционирование.

Раздел 3. Требования к видам обеспечения системы

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

Информационное обеспечение
В этом разделе определяются:
• Системы классификации и кодирования. Классификатор нужен для обобщения данных (например, чтобы выделить категорию «грузчики» по всем предприятиям).
• Внутримашинная информационная база. На уровне ТЗ вы определяете, какую модель базы данных планируете использовать (например, реляционную, где данные хранятся в связанных таблицах) и будете ли вы покупать готовую СУБД или разрабатывать собственную.

Лингвистическое обеспечение
Это совокупность языков для работы с системой. Обычно это подмножество естественного языка (русский). Также могут использоваться командные языки. Источником требований здесь служит документация заказчика и ваш собственный опыт.

Программное обеспечение
На уровне ТЗ вы определяете глобальные характеристики: с какими библиотеками и под управлением какой операционной системы будет работать ваша система.

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

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

Организационное обеспечение
В этом разделе мы определяем:
• Состав документов, которые необходимо создать для правового обеспечения работы системы (инструкции, регламенты).
• Юридические нормы, касающиеся работы с системой и ее результатами, а также ответственности.
Источником информации может служить ГОСТ Единой системы программной документации (ЕСПД).

Состав и содержание работ по созданию системы
Здесь вы фиксируете этапы, через которые пройдет проект. Этапы выбираются из соответствующего ГОСТа не механически, а на основе анализа вашего конкретного проекта: что-то можно пропустить (например, эскизное проектирование), а что-то объединить.

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

Требования к документированию
Определяется, в каком виде и по каким правилам должны быть оформлены документы на разных этапах проекта, а также их состав (ведомость документов). Последним пунктом указываются источники для разработки системы.

Раздел 4. Управление требованиями и жизненный цикл системы
Если в процессе реализации выясняется недопонимание или нехватка информации, запускается процедура управления требованиями. Разработчик и заказчик по взаимному согласованию вносят изменения. Важно отследить, как изменение одного требования повлияет на другие, вплоть до корректировки разбивки на подсистемы. В конце курса мы рассмотрим тему «Управление требованиями» подробнее.
Изменения могут оформляться протоколом, который становится неотъемлемой частью ТЗ, без перевыпуска всего документа.
Современные системы динамично развиваются, поэтому заказчик часто требует масштабируемости (наращивание рабочих мест и объемов информации без переделки системы) и модифицируемости. Задачи, связанные с модернизацией системы, обычно выносятся в отдельный проект или этап сопровождения. Сопровождение в среднем требует около 15% от стоимости системы в год. Если же изменения затрагивают бизнес-логику, которая не была учтена при проектировании, стоимость доработок может быть очень высока. Хорошая система должна нормально отработать без серьезных модификаций 2–3 года.

Раздел 5. Технический проект (ТП)
Технический проект — это описание того, как мы будем реализовывать требования ТЗ. Если в ТЗ требования сформулированы в ключе «что должно быть», то в ТП они излагаются в утвердительной форме: «система выполняет то-то». Часть информации можно перенести из ТЗ, изменив стиль изложения. ТП должен содержать решения по общесистемным, организационным, техническим, информационным и программным вопросам.
Для экономических корпоративных систем не нужно использовать все документы из ГОСТа, достаточно сохранить стройность изложения через следующие разделы:
1. Пояснительная записка: общая характеристика проекта.
2. Описание входной и выходной информации: перечень входных сигналов и данных (источник — ERD-диаграммы, диаграммы классов) и перечень выходных документов (источник — ERD-диаграммы, альбомы форм заказчика).
3. Описание функциональной и организационной структуры: схема деления системы на подсистемы (например, подсистема хранения данных, управления НСИ) и описание информационных связей между ними через интерфейсы прикладного программирования (API) или общие таблицы базы данных. Также описывается, как изменится организационная структура объекта автоматизации в связи с внедрением системы.
4. Постановка задач и алгоритмы их решения:
o Описание автоматизируемых функций: систематизирует информацию из ТЗ.
o Описание комплекса задач: содержит перечень объектов и общую характеристику.
o Описание алгоритма: детально объясняет логику решения конкретной задачи (например, «Аналитическая обработка данных») с помощью блок-схем и описания входных/выходных данных.
5. Описание программного обеспечения: структура, функции частей ПО, системные и прикладные средства разработки.
6. Описание информационного обеспечения: фиксируется организация внутримашинной базы данных, ее размещение на носителях (с расчетом объемов циркулирующей информации) и используемые классификаторы и методы кодирования.
7. Комплекс технических средств: архитектура, характеристики и связи технических средств.

Краткие итоги

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

На этапе ТЗ закладывается правовой и функциональный фундамент системы. Здесь принципиально важно перейти от поверхностных ожиданий к исчерпывающему перечню формализованных требований. Особую значимость приобретают аспекты, которые часто упускают из виду в угоду функционалу. Это обеспечение патентной чистоты, что напрямую влияет на совокупную стоимость владения системой, и требования по стандартизации и унификации, от которых зависит удобство пользователей. Анализ подхода к структурированию ТЗ показывает важность работы с источниками: одни требования (как условия эксплуатации) берутся из документации на технические средства, другие (как функции подсистем) — извлекаются из моделей бизнес-процессов (IDEF0, IDEF3, DFD, ERD). Игнорирование какого-либо раздела недопустимо и требует явной записи «требования не задаются», что дисциплинирует процесс.

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

Технический проект превращает «что» в «как». Здесь в чистом виде проявляется переход от требований к конкретным архитектурным и алгоритмическим решениям. Детальная проработка входных и выходных данных, структурирование системы на подсистемы с описанием интерфейсов между ними и, наконец, алгоритмизация каждой задачи — это итеративный и трудоемкий процесс, но именно он минимизирует неопределенность на этапе разработки. Практическая ценность такого подхода в том, что на выходе формируется не просто том документации, а точный набор инструкций для настройки типового ПО или техническое задание для программирования уникальных компонентов, что делает процесс разработки предсказуемым и управляемым.