Введение
На предыдущем занятии мы рассмотрели процедуры канонического проектирования информационной системы (ИС). Ключевыми этапами являются разработка технического задания (ТЗ) и описание проекта. Оба документа регламентированы стандартами
ГОСТ 34-й серии. Несмотря на свой возраст, этот стандарт полезен благодаря глубокой формализации. Сейчас нет жестких требований неукоснительно следовать его структуре, но он служит хорошей основой и подсказкой: что должно содержаться в документе, в каком порядке и как структурировать материал.
На первый взгляд сформулировать требования к будущей системе просто. Однако при попытке написания документа возникает множество проблем: откуда брать информацию, как ее формулировать и структурировать, какие формулировки допустимы, а какие нет. Чтобы приобрести практические навыки, сегодня мы рассмотрим пример формирования ТЗ и технического проекта для конкретной системы.
Характеристика примера: система учета кадров
В качестве примера взята гипотетическая система для Федерального агентства учёта кадров государственных предприятий. Она должна обеспечивать накопление, анализ и выдачу справочно-аналитической информации о государственных служащих. Заказчик — федеральное агентство с региональными представительствами, система будет территориально распределенной и состоять из взаимосвязанных подсистем.
Функциональная декомпозиция деятельности агентства выполнена в нотации
IDEF0. Контекстная диаграмма верхнего уровня: «Деятельность федерального агентства». Первый уровень декомпозиции выделяет четыре основные функции:
• учёт персонала;
• управление персоналом;
• анализ состояния дел с персоналом;
• взаимодействие с населением.
Далее каждая функция детализируется. Например, функция «Учёт персонала» на втором уровне включает:
• введение нормативно-справочной информации (классификаторы, справочники) и её актуализацию;
• сбор и хранение информации о структуре госучреждений с учётом реорганизаций;
• ведение архивов данных для аналитической обработки.
Функция «Управление персоналом» декомпозируется на:
• планирование структуры организаций;
• разработку штатных расписаний;
• определение кадровой политики;
• расчёт заработной платы;
• учёт движения кадров;
• ведение кадрового документооборота.
Третий уровень детализирует, например, «планирование структуры организации» через создание корпоративной структуры, поддержку множественных иерархий и т.д. Подобная многоуровневая функциональная модель служит основой для выявления требований.
Структура технического задания по ГОСТ
Структура ТЗ определена стандартом и включает девять основных разделов. Последовательно рассмотрим, чем наполнять каждый из них и откуда брать информацию.
1. Общие положения
Раздел содержит формальную информацию о проекте, системе и заказчике. Включает подпункты: полное и краткое наименование системы, условное обозначение (шифр темы), сведения о заказчике, основание для разработки, плановые сроки, источник финансирования, порядок передачи системы, перечень используемых нормативных документов.
Эти данные получают из госконтракта или тендерной документации. Пример заполнения:
• Полное наименование: Единая автоматизированная система учёта кадров всех государственных предприятий.
• Краткое наименование: АС-кадры.
• Шифр темы: применяется при закрытой тематике.
• Заказчик: указывается с адресом.
• Порядок передачи: система передаётся в виде готового функционирующего комплекса на технических средствах заказчика.
• Нормативные документы: ГОСТ 34, стандарты ISO, корпоративные методики.
Этот раздел служит шаблоном и заполняется без особых затруднений.
2. Назначение и цели создания системы
Описание назначения должно давать ясное представление о том, что именно будет делать система, не вдаваясь в излишнюю детализацию. Если указать лишь общую фразу «информационно-аналитическое обеспечение», останется непонятным, какие процессы автоматизируются. Чрезмерная подробность (уровень 3-4 декомпозиции) перегрузит документ.
Рекомендуется использовать
второй уровень декомпозиции IDEF0, где функции конкретны, но обозримы. Пример: «Автоматизированная система кадров предназначена для комплексного информационно-аналитического обеспечения процессов Федерального агентства “Государственные кадры” в части: ведения нормативно-справочной информации, сбора и хранения сведений о структуре госпредприятий, ведения архивов…» Допустимы ссылки на другие документы.
Цели создания системы должны формулироваться так, чтобы можно было проверить их достижение. Абстрактные лозунги («повышение качества») без критериев недопустимы. Возможные цели:
• замещение устаревшей системы;
• повышение эффективности процессов (сокращение дублирования, ускорение);
• повышение качества управленческих решений;
• повышение информационной открытости и прозрачности деятельности.
Критериями достижения могут быть не только числовые показатели (которые часто трудно определить на этапе ТЗ), но и
перечень конкретных задач. Если эти задачи решены — цель достигнута.
Информацию берут из организационно-функциональной модели, диаграмм IDEF0, стратегических документов заказчика и материалов обследования.
3. Характеристика объекта автоматизации
Объект автоматизации — это не только
бизнес-процессы, но и
организационные единицы (подразделения, специалисты), которые их исполняют. Важно чётко ограничить область проекта, указав:
• автоматизируемые процессы (со ссылкой на раздел назначения);
• подразделения и сотрудников, участвующих в них (из оргштатной структуры и матрицы проекций);
• существующее
программное обеспечение (какие системы работают и что решают);
• существующий комплекс
технических средств, куда будет устанавливаться новая система;
•
нормативно-правовое обеспечение (Конституция, законы, ведомственные инструкции и регламенты). Эти документы отображаются на диаграммах IDEF0 как стрелки управления.
4. Требования к системе
Раздел состоит из трёх блоков: требования к системе в целом, требования к функциям и задачам, требования к видам обеспечения. Детально рассмотрен первый блок.
4.1. Требования к системе в целом
Структура и функционирование. При каноническом проектировании подсистемы выделяются не только по функциональным областям, но и по типу решаемых задач. Для рассматриваемой системы предложено такое разбиение:
• Подсистема хранения данных (накопление, архивирование);
• Подсистема приложений операционного уровня (оперативное управление кадрами);
• Подсистема управления нормативно-справочной информацией (классификаторы, справочники);
• Подсистема анализа (аналитическая обработка);
• Подсистема интеграции (связь с существующими внешними системами);
• Подсистема формирования отчётности (регламентированная отчётность);
• Открытый ведомственный информационный ресурс (портал для взаимодействия с населением).
Допустимы иные варианты группировки — это поле проектных решений, опирающихся на функции, выявленные в IDEF0.
Способы и средства связи между компонентами. Определяются требования к информационному обмену между подсистемами. Обычно указывают использование открытых стандартов (
XML,
HTML). Конкретные форматы данных детализируют позже, в техническом проекте.
Взаимосвязь со смежными системами. Описывается взаимодействие с внешними системами, не создаваемыми в проекте. Фиксируются виды обмена (экспорт, импорт) и группы информации. Источник — диаграммы потоков данных (
DFD) и IDEF0.
Режимы функционирования. Выделяют
нормальный режим (график работы, время на профилактику, допустимые простои) и
аварийный режим (главное требование — сохранность и целостность данных). Данные получают из документации заказчика.
Диагностирование системы. Требования к проверке работоспособности формулирует разработчик, опираясь на опыт эксплуатации подобных систем, методологии
ITIL (IT Infrastructure Library) или
MOF (Microsoft Operations Framework). Заказчик обычно не компетентен в этом вопросе.
Перспективы развития и модернизация. Сведения берут из стратегии развития организации и проецируют на ИТ-инфраструктуру.
Требования к персоналу. Целесообразно описывать
роли, необходимые для эксплуатации системы, их квалификацию и функции, а не жёсткое штатное расписание. Источник — опыт и характеристики выбранных программно-технических средств.
Показатели назначения. Включают производительность, надёжность и т.п. Для их обоснования используют нижние уровни IDEF0, показывающие конкретные операции и ограничения, а также данные анкет.
Требования к надёжности. Формулируются разработчиком как техническим специалистом на основе теории надёжности и согласовываются с заказчиком. Из моделей прямо не выводятся.
Требования к безопасности. Охватывают техническую безопасность (электрическую, строительную и пр.), а не информационную.
Требования к эргономике и технической эстетике. Описывают характеристики интерфейса, формы отображения информации. Опираются на знания в области инженерной психологии и эргономики; функциональные модели состав отображаемой информации выявляют, но качественные параметры — нет.
Краткие итоги
Разработка технического задания при каноническом проектировании предстаёт не как механическое заполнение пунктов стандарта, а как многослойный аналитический процесс, в котором формальная структура ГОСТ 34 служит каркасом, удерживающим полноту требований. Логика движения — от общего к частному: сначала фиксируются рамочные условия проекта, затем определяется его содержательное ядро через назначение и цели, после чего объект автоматизации очерчивается не только как набор процессов, но и как совокупность вовлечённых подразделений, существующих ИТ-активов и нормативной среды. Такой подход предотвращает неверное толкование границ системы.
Центральный методологический приём — использование функциональной модели IDEF0 как основного источника содержательных требований. Важно, что для каждого раздела ТЗ рекомендуется свой уровень декомпозиции: для назначения — второй, для выделения подсистем — третий и ниже, а для показателей назначения — самый детальный. Это позволяет дозировать информацию, избегая как пустых деклараций, так и перегрузки документа. Принципиально, что модель задаёт лишь часть требований; ряд блоков (надёжность, эргономика, диагностика, безопасность) требует прямого привлечения инженерного опыта и специализированных знаний разработчика, а также активной работы с документацией заказчика.
Красной нитью проходит императив проверяемости. Цели, не снабжённые критериями достижения, обесценивают ТЗ как инструмент приёмки. Прагматично предложена замена отсутствующих числовых метрик перечнем решаемых задач: если задачи выполнены — цель достигнута. Такой компромисс сохраняет объективность оценки без погони за трудновычислимыми показателями на ранней стадии.
Практическая значимость изложенного подхода в том, что он превращает ТЗ из бюрократической формальности в рабочий инструмент управления проектом. Чёткая атрибуция источников информации по каждому разделу (модели, контракт, анкеты, стратегия, личный опыт) делает процесс наполнения документа воспроизводимым и обоснованным, снижая риск пропуска критических требований.
1. ГОСТ 34-й серии при необязательности соблюдения остаётся эффективным шаблоном, обеспечивающим структурную полноту технического задания.
2. Написание ТЗ — аналитическая задача, требующая не механического заполнения, а осмысленного синтеза данных из моделей, документов и профессионального опыта.
3. Ключевой источник содержательных требований — функциональная модель IDEF0, но для разных разделов ТЗ используется разная глубина её декомпозиции.
4. Назначение системы следует описывать на основе второго уровня декомпозиции, чтобы достичь баланса между конкретностью и обозримостью.
5. Цели создания системы обязательно должны сопровождаться проверяемыми критериями; при отсутствии числовых показателей допустимо использовать перечень реализуемых задач.
6. Объект автоматизации включает не только процессы, но и организационные единицы, существующее ПО, технические средства и нормативно-правовую базу.
7. При каноническом проектировании подсистемы выделяются по типу решаемых задач (хранение, операционная работа, анализ, интеграция и др.), а не только по функциональным областям.
8. Требования к режимам функционирования, надёжности, диагностике и эргономике лишь частично выводятся из моделей; их основа — техническая компетенция разработчика и стандарты.
9. Информационный обмен между подсистемами должен специфицироваться через открытые стандарты; детальные форматы фиксируются на стадии технического проекта.
10. Требования к персоналу целесообразно формулировать в терминах ролей и квалификации, а не фиксированного штатного расписания.
11. Показатели назначения (производительность, надёжность) опираются на ограничения, выявленные на детальных уровнях описания процессов.
12. Эргономические и эстетические требования к интерфейсу базируются на инженерной психологии, поскольку пользователи редко формулируют их самостоятельно.
1. Почему ГОСТ 34-й серии рекомендуется использовать при подготовке ТЗ, несмотря на его необязательность?
2. Какой уровень декомпозиции IDEF0 оптимален для описания назначения системы и почему?
3. Каким образом можно обеспечить проверяемость цели создания ИС, если невозможно задать числовые критерии?
4. Какие компоненты, помимо бизнес-процессов, необходимо указать в характеристике объекта автоматизации?
5. В чём отличие логики выделения подсистем при каноническом проектировании от типового?
6. Какие источники информации используются для формулирования требований к режимам функционирования системы?
7. Почему требования к диагностированию системы не могут быть получены от заказчика?
8. Какие стандарты целесообразно указывать для обеспечения информационного обмена между подсистемами?
9. Чем требования к взаимосвязям со смежными системами отличаются от требований к связи между внутренними подсистемами?
10. На основе чего формируются количественные показатели назначения (производительность, надёжность)?
11. В какой форме рекомендуется описывать требования к персоналу, эксплуатирующему систему?
12. Почему требования к эргономике формулируются проектировщиком, а не заказчиком?
