Каноническое и индустриальное проектирование информационной системы

Каноническое проектированиеИС предполагает создание индивидуального проекта по заданию заказчика.На сегодняшний день технологию канонического проектирования используют при разработке сравнительно небольших ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания».

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

Стадия 1. Формирование требований к ИС - обследование объекта и обоснование необходимости создания ИС; формирование требований пользователей к ИС; оформление отчета о выполненной работе и тактико-технического задания на разработку. Oбследование- это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются для обоснования разработки и поэтапного внедрения систем; составления технического задания на разработку систем; разработки технического и рабочего проектов систем.

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

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

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

На этапе обследования следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации – MuSCoW (Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствующие функции).

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

Модели деятельности организации создаются в двух видах:

модель "как есть"("as-is")- отражает существующие в организации бизнес-процессы;

модель "как должно быть"("to-be") - отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.

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

Стадия 3. Техническое задание - разработка и утверждение технического задания на создание ИС. Техническое задание- это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления. При разработке технического задания необходимо решить следующие задачи (ГОСТ 34.602- 89):

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

Стадия 4. Эскизный проект. - разработка предварительных проектных решений по системе и ее частям; разработка эскизной документации на ИС и ее части.

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

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

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

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

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

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

Стадия 8. Сопровождение ИС - выполнение работ в соответствии с гарантийными обязательствами; послегарантийное обслуживание. К основным работам на стадии сопровождения относятся: анализ функционирования системы; Выявление отклонений фактических эксплуатационных характеристик ИС от проектных значений; Установление причин этих отклонений; Устранение выявленных недостатков и обеспечение стабильности эксплуатационных характеристик ИС; Внесению необходимых изменений в документацию на ИС

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

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение.

Выделяют следующие классы ТПР:

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

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

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

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

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

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

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

Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства. Репозиторий содержит базовую (ссылочную) модель ИС (содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС), типовые (референтные) модели определенных классов ИС (описывают конфигурации информационной системы для определенных отраслей или типов производства), модели конкретных ИС предприятий (строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench)). Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы.

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

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

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

Обычно выделяют следующие этапы создания ИС:

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

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

- Реализация - создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации;

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

обнаружение отказов модуля (жестких сбоев);

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

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

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

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

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

- ввод в действие – промышленная эксплуатация ИС;

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

Техническое задание (ТЗ) на создание ИС является основным документом, определяющим требования и порядок создания, в соответствии с которым проводится разработка ИС и ее приемка при вводе в действие ИС.

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

ТЗ на ИС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;.

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

В разделе «Общие сведения» указывают:

• полное наименование системы и ее условное обозначение;

• шифр темы или шифр (номер) договора;

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

• перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

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

• сведения об источниках и порядке финансирования работ;

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

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

• назначение системы, в котором указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать. Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

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

В разделе «Характеристики объекта автоматизации» приводят:

• краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

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

Раздел «Требования к системе» состоит из следующих подразделов:

1) Требования к системе в целом. Здесь указывают:

a) требования к структуре и функционированию системы включают:

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

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

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

• требования к режимам функционирования системы;

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

• перспективы развития, модернизации системы.

b) требования к численности и квалификации персонала системы и режиму его работы включают:

• требования к численности персонала (пользователей) АС;

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

• требуемый режим работы персонала АС.

c) показатели назначения. – приводят значения параметров, характеризующие степень соответствия системы ее назначению. Для АСУ указывают: степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления; допустимые пределы модернизации и развития системы; вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

d) требования к надежности включают:

• состав и количественные значения показателей надежности для системы в целом или ее подсистем;

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

• требования к надежности технических средств и программного обеспечения;

• требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

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

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

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

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

• предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.;

• требования по количеству, квалификации обслуживающего персонала и режимам его работы;

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

• требования к регламенту обслуживания.

h) требования к защите информации от несанкционированного доступа;

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

j) требования к защите от влияния внешних воздействий включают:

требования к радиоэлектронной защите средств АС;

требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

к) требования к патентной чистоте включают перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей;

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

m) дополнительные требования включают:

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

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

• требования к системе, связанные с особыми условиями эксплуатации;

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

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

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

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

ü временной регламент реализации каждой функции, задачи
(или комплекса задач);

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

ü перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

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

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

ü Для информационного обеспечения системы приводят требования:

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

- к информационному обмену между компонентами системы;

- к информационной совместимости со смежными системами;

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

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

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

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

- к контролю, хранению, обновлению и- восстановлению данных;

- к процедуре придания юридической силы документам, продуцируемым техническими средствами ИС.

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

Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:

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

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

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

Для технического обеспечения системы приводят требования:

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

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

В требованиях к метрологическому обеспечению приводят:

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

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

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

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

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

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

Для организационного обеспечения приводят требования:

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

• к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

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

Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т. п.).

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

В данном разделе также приводят:

· перечень документов, предъявляемых по окончании соответствующих стадий и этапов работ;

· вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);

· программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);

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

В разделе «Порядок контроля и приемки системы» указывают:

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

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

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

В перечень основных мероприятий включают:

· приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

· изменения, которые необходимо осуществить в объекте автоматизации;

· создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;

· создание необходимых для функционирования системы подразделений и служб;

· сроки и порядок комплектования штатов и обучения персонала.

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

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

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