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

Техническое задание – документ, регламентирующий состав требований к создаваемой системе и определяющий взаимоотношения между заказчиком и разработчиком.

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

При разработке ТЗ предполагается, что производственная сфера модифицирована и соответствует целям, стоящим перед рассматриваемым объектом.

Оформление ТЗ осуществляется в соответствии с ГОСТ 34.602-89.

1. Раздел «Общие сведения»

В данном разделе указывают общие характеристики создаваемой системы и участников разработки.

1. Полное наименование системы и ее условное обозначение

Полное наименование системы обычно связано с назначением системы или с локализацией объекта автоматизации. Под локализацией понимается формирование перечня элементов, включаемых в систему. В этом случае проводится анализ степени связанности элементов (объем передаваемой информации) и размещения элементов по структуре объекта. Можно выделить внешние системы (элементы), которые рассматриваются как источники или приемники информации выделенной системы. Например: «Информационная система малого предприятия»; «АРМ маркетолога». Сокращенное наименование системы вводится для снижения трудоемкости оформления проектной документации. Например: ИС МП, АРМ-М.

2. Шифр темы или шифр (номер) договора

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

3. Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты

Указываются полные наименования организаций разработчика и заказчика, их юридические адреса и контактные телефоны, факсы и т.п.

4. Перечень документов, на основании которых создается система, кем и когда утверждены эти документы

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

5. Плановые сроки начала и окончания работы по созданию системы

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

6. Сведения об источниках и порядке финансирования работ

Сведения характеризуют источники финансирования проекта и финансовые отношения между заказчиком и разработчиком. В этом пункте определяется порядок финансовых расчетов между заказчиком и разработчиком.

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

Пункт регламентирует:

• {что} передается заказчику;

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

• как оформляется каждый элемент из {что}.

Заказчику можно передавать загрузочный модуль, комплекс программ, пакет прикладных программ, дистрибутив, технический проект, рабочий проект, техно-рабочий проект, инструкции пользователям, результаты НИР и ОКР и т.п. Необходимо определить, что конкретно передавать заказчику, в какой последовательности (по мере завершения отдельных частей системы или по завершению всей разработки) передаются материалы. По каждому элементу из {что} определяется тип носителя, формат представления, количество экземпляров и т.п.

2. Раздел «Назначение и цели создания (развития) системы»

Данный раздел определяет назначение создаваемой (модифицируемой) системы и количественные значения целей создания системы, и состоит из подразделов:

1. Назначение системы

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

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

Для ИС необходимо дополнительно перечислить подразделения объекта, деятельность которых подвергается автоматизации с указанием управляемых объектов.

2. Цели создания системы

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

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

3. Раздел «Характеристика объекта автоматизации»

Раздел необходим для оценки размерности ИС. Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию.

В этом пункте приводятся организационная, функциональная и/или производственная структура объекта, по которым можно выделить элементы системы. Помимо этого в данном пункте приводится перечень и интенсивность информационных потоков, и объемы номенклатур, используемых в процессах обработки. Например: можно разрабатывать ИС для учета 3-х видов товаров, но можно создавать проект и для учета 10000 видов товаров, категории сложности задачи будут различны. Кроме того, приводятся другие параметры объекта автоматизации: количество источников и приемников информации, количество функций (задач), периодичность реализации функций, количество исполнителей.

1. Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды

Указываются сведения об условиях эксплуатации и характеристики окружающей среды. Это необходимо при создании ИС, где возможны вибрация, удары, сильное запыление, высокая (низкая) температура окружающей среды и т.п.

4. Раздел «Требования к системе»

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

1. Требования к структуре и функционированию системы

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

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

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

В первом случае рассматривается структура аппаратного обеспечения (структура сети) и иерархия определяется по графу связи технических средств.

Во втором случае допустимы три варианта:

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

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

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

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

При проработке ТЗ должны рассматриваться вопросы архитектуры ИС, т.е. связи рассматриваемой системы со смежными системами. Предполагается, что при обследовании объекта автоматизации выявлены все смежные системы, определена соподчиненность, выявлены информационные потоки и имеется их параметрическое описание (объемы информации, периодичность и т.п.). В данном пункте должны быть перечислены все смежные системы, указана их соподчиненность и требования к обмену информацией между рассматриваемой и смежными системами (периодичность, объемы, типы носителей, способы передачи).

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

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

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

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

2. Требования к численности и квалификации персонала системы и режиму его работы.

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

• информатика на базе 9 классов общеобразовательной школы;

• информатика на базе 11 классов общеобразовательной школы;

• информатика в объеме средне - технического образования (общее);

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

• информатика в объеме высшей школы (общее);

• информатика в объеме высшей школы (специальное).

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

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

3. Показатели назначения

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

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

Степень приспособляемости (адаптации) ИС к изменению процессов и методов управления характеризует допустимую модификацию ИС без привлечения разработчиков (открытость системы). Если система закрытая, то малейшие изменения в структурах данных или алгоритмах приведет к разработке новой системы (попробуйте модифицировать ОС Windows). Если система открытая, то можно выполнить модификацию системы при значительных изменениях. В MS Excel Вы можете изменить структуры данных и пополнить систему новыми функциями с помощью макросов или модулей, написанных на VBA.

4. Требования к надежности

Надежность ИС зависит от многих факторов. Можно рассматривать надежность технических средств, надежность программных средств, достоверность информации, адаптивную надежность системы. Для информации термин надежность обычно не применяют, а используют термин достоверность. Он аналогичен надежности. Требования к надежности зависят от класса системы. Для систем реального времени, где сформированы повышенные требования к скорости восстановления системы, предусматривается горячее резервирование, предусматривающее резервные технические средства, находящиеся в рабочем состоянии и автоматически включаемые в работу при выходе из строя основных технических средств.

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

5. Требования безопасности

Вспомогательный раздел, формируется на основе материалов курса «Безопасность жизнедеятельности».

6. Требования к эргономике и технической эстетике

В данном разделе требуется определить термины «эргономика» и «техническая эстетика» и сформировать требования по данному разделу. Эргономика – наука о взаимодействии человека и технических средств.

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

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

7. Требования к транспортабельности для подвижных ИС

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

8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

9. Требования к защите информации от несанкционированного доступа

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

10. Требования по сохранности информации при авариях

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

11. Требования к защите от влияния внешних воздействий

Вспомогательный раздел, формируется для ИС работающих в агрессивных средах (подвижные ИС, АСУ ТП и т.п.).

12. Требования к патентной чистоте

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

13. Требования по стандартизации и унификации

Стандарт – нормативно-технический документ, устанавливающий комплекс норм, правил, требований к объекту стандартизации и утвержденный компетентным органом. Применение стандартов способствует улучшению качества продукции, повышению уровня унификации и взаимозаменяемости, росту эффективности эксплуатации. Различают государственные, отраслевые, республиканские и стандарты предприятия. Стандартизация сокращает номенклатуру оригинальных элементов системы и используемых технологий. Например, в ГОСТ 34,602-89 регламентирован состав и содержание документа – ТЗ на ИС. Это позволяет значительно упростить формирование разделов документа и проводить сравнение ТЗ на различные ИС.

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

14. Дополнительные требования

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

15. «Требования к функциям (задачам)», выполняемым системой

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

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

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

5. Раздел «Требования к видам обеспечения»

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

1. Требования к математическому обеспечению

На основе анализа материалов обследования (алгоритмов решаемых задач) определяется состав, область применения и способы использования математических методов и моделей, типовых (стандартных) алгоритмов и алгоритмов, подлежащих разработке.

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

К способам использования относят технологию реализации выбранных методов. Можно разрабатывать алгоритмы реализации методов самостоятельно, но допустима реализация с использованием распространяемых на рынке программных продуктов (ППП MatLab, MathCad, Статистика и т.п.).

2. Требования к информационному обеспечению системы

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

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

1. К составу, структуре и способам организации данных в системе

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

2. Информационному обмену между компонентами системы

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

3. Информационной совместимости со смежными системами

В данном пункте формируются требования к архитектуре информационной среды. По материалам обследования выявлены смежные системы и формируются требования к языкам взаимодействия систем и регламенту взаимодействия. Например: при использовании внутреннего классификатора продукции можно записать следующее требование – при обмене информацией с системой Госстатистики осуществляется перекодировка информации с использованием общегосударственного классификатора ВКГОКП. При использовании сетевых технологий необходимо указать требования к применяемым протоколам.

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

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

ОКОНХ – общегосударственный классификатор отраслей;

ОКПО - общегосударственный классификатор предприятий и организаций;

Документы бухгалтерского учета – положение министерства финансов № 285/2 от 1.01.96. о бухгалтерском учете на малых предприятиях.

5. По применению систем управления базами данных

В данном пункте формируются требования по применению СУБД и определяется класс применяемых СУБД (настольные, серверные).

6. К структуре процесса сбора, обработки, передачи данных в системе и представлению данных

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

7. К защите данных от разрушений при авариях и сбоях в электропитании системы

В ТЗ уже сформированы требования (пункт 4.1.9) по сохранности информации в ИС. В данном пункте формируются дополнительные требования по сохранности внутреннего ИО. Необходимо указать требования к резервному копированию, архивированию удаленных записей, восстановлению данных при сбоях и синхронизации данных в распределенной системе.

8. К контролю, хранению, обновлению и восстановлению данных

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

3. Требования к лингвистическому обеспечению системы

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

1. Способы организации диалога с пользователями зависят от категории пользователей

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

2. Требования к языкам разработки ИС

Требования зависят от метода проектирования. При объектном или подсистемном методах, когда применяется готовый программный продукт, используется язык ППП (1С – язык пакета 1С, ППП Галактика – используется язык «Галактики»). Однако множество ППП допускает применение типовых языков программирования: Pascal, C++ и т.п. Если ИС реализуется в среде какой либо СУБД, то можно использовать язык СУБД. При элементном проектировании язык проектирования зависит от языка, на котором написаны программы для большинства типовых элементов. При индивидуальном проектировании требования к языку формируются на основе специфики обрабатываемой информации и полноты библиотек среды программирования, например, при проектировании подсистемы конструкторской подготовки производства целесообразно использовать ППП AutoCAD, который ориентирован на обработку графической информации. ППП AutoCAD поддерживает программирование на языке AutoLisp, разновидности языка Lisp.

3. Требования к кодированию и декодированию данных

Формируются на основе связей с другими ИС (архитектуре информационной системы) и используемых языках (классификаторах и формах документов) при взаимодействии ИС. В материалах обследования перечислены смежные ИС, выявлена соподчиненность ИС, объемы передаваемых данных и периодичность обмена, используемые классификаторы. На основе анализа указанных параметров формируются требования к языкам взаимодействия ИС.

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

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

5. Требования к языкам ввода – вывода

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

6. Требования к языкам манипулирования данными

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

4. Требования к программному обеспечению системы

Основное требование в данном разделе – перечень классов покупных программных средств: операционных систем, антивирусных программ, пакетов прикладных программ специализированного назначения (оболочек, архиваторов и т.п.). Кроме этого необходимо, в зависимости от специфики разработки сформировать требования ко вновь создаваемому программному обеспечению.

1. К независимости программных средств от используемых СВТ и операционной среды

Требования формируются в случае тиражирования создаваемой ИС на множестве объектов.

2. К качеству программных средств, а также к способам его обеспечения и контроля

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

3. По необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ

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

5. Требования к техническому обеспечению системы

Формируется номенклатура классов технических средств (комплексов) допустимых к использованию в проектируемой ИС. Можно выделить следующие классы технических средств:

• вычислительная техника;

• сетевое оборудование;

• копировально – множительное оборудование;

• оборудование связи;

• мультимедийное оборудование и т.п.

По каждому классу технических средств необходимо указать требования к выполняемым функциям и эксплуатационным характеристикам. Например: копировальная техника должна обеспечивать масштабирование (зуммирование) в пределах 0,5 – 3,0 и обеспечивать обработку документов формата 0,9м * 10м со скоростью копирования 10 метров в минуту.

6. Требования к метрологическому обеспечению

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

1. Предварительный перечень измерительных каналов, обычно соответствует количеству параметров фиксируемых измерительными системами;

2. Требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов

В данном случае указывается точность измеряемых параметров по каждому измерительному каналу пункта 5.6.1., например, точность взвешивания на вагонных весах не должна быть менее 200 кг.;

3. Требования к метрологической совместимости технических средств системы

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

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

Учитывая, что точность измерений существенно влияет на результаты деятельности системы, необходимо привести перечень измерительных и управленческих каналов, по которым требуется учитывать точностные характеристики.

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

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

7. Требования к организационному обеспечению

Формируются с учетом целей проектирования ИС и должны отражать требования к изменениям в организационной структуре.

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

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

2. К организации функционирования системы и порядку взаимодействия персонала ИС и персонала объекта автоматизации

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

3. К защите от ошибочных действий персонала системы

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

действий пользователей системы.

8. Требования к методическому обеспечению ИС

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

6. Раздел «Состав и содержание работ по созданию (развитию) системы»

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

В данном разделе приводят перечень стадий, этапов и документов (ГОСТ 34.201) передаваемых заказчику в виде, представленном на рис.2.

№ п/п	Наименование стадии (этапа) проектирования	Наименование документа	Форма представления	Срок представления	Примечание

Рис.2. Таблица «Состав и содержание работ по созданию (развитию) системы»

Примечание: в дипломных проектах допускается вместо стадий и этапов включать отдельные проектные работы.

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

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

7. Раздел «Порядок контроля и приемки системы»

Должен содержать:

• статус приемочной комиссии (государственная, межведомственная, ведомственная);

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

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

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

• место проведения испытаний.

8. Раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»

Раздел содержит план организационно – технических мероприятий по подготовке объекта к внедрению ИС. Детально требования представлены в ГОСТ 34.602-89.

9. Раздел «Требования к документированию»

Раздел должен содержать следующие пункты:

1. Согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях;

2. Требования к микрофильмированию документации;

3. Требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

10. Раздел «Источники разработки»

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

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