Основные стадии создания асу

Введение

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

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

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

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

1. Регламентация порядка разработки

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

АСУ является сложной системой, состоящей из взаимосвязанных подсистем функционального и обеспечивающего назначения. Если на предприятии или в производственном объединении создается специализированная АСУ, например автоматизированного проектирования, и функционирует АСУ предприятием, то должно быть обеспечено их тесное взаимодействие. АСУ предприятием или производственным объединением также должна взаимодействовать с отраслевой АСУ в соответствии с подчиненностью, а также с АСУ тех предприятий и объединений, с которыми существуют производственные или иные связи. Взаимодействие предусматривает прежде всего функциональные связи по решаемым задачам, которые для отраслевых АСУ и АСУ предприятиями реализуются в рамках функциональных подсистем. Задачи, решаемые на уровне предприятия, выдают исходную информацию для решения аналогичных, но обобщенных задач на уровне отрасли. В то же время задачи отраслевого уровня создают управляющую информацию для задач предприятия. В "ручных" системах такие связи реализуются в виде документо-потоков, в наиболее развитых АСУ - по каналам связи между ЭВМ, что требует соответствующих технических средств, лингвистического и программного обеспечения.

АСУ производственным объединением создается, как правило, на базе собственного вычислительного центра (ВЦ) с разветвленной сетью терминалов различного типа. В соответствии с ОРММ разработчиком АСУ являются специализированные научно-исследовательские и проектные организации. Заказчиком таких работ являются производственные объединения и предприятия, для которых создается АСУ. В некоторых случаях предприятие или объединение создает АСУ самостоятельно, используя специальное подразделение ВЦ или вне его. В этом случае оно само получает права, обязанности и несет ответственность как разработчик.

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

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

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

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

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

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

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

В процессе разработки и внедрения АСУ создается различная предпроектная и проектная документация, предусмотренная государственными стандартами (см. гл. 9) и оформляемая в соответствии с ними.

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

2. Предпроектная стадия создания АСУ

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

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

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

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

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

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

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

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

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

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

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

Важной частью предпроектной стадии создания АСУ является анализ предприятия, направленный на выявление общих тенденций и факторов развития производства; целей и критериев эффективности функционирования и развития производства; факторов, препятствующих и способствующих достижению целей; общих и специфических характеристик развития предприятия, его роли и места в общем комплексе деятельности отрасли и в народном хозяйстве. Наиболее важным и наименее формализуемым является определение целей функционирования предприятия и критериев эффективности управления им. Для этого целесообразно использовать уже сформулированные цели и критерии вышестоящей системы управления, т.е. для предприятия производственного объединения, а для последнего - отрасли в целом. Если такие цели и критерии ранее не были сформулированы, следует самим разработчикам сделать, по крайней мере, обоснованную прикидку. Используя экспертные методы построения дерева целей, доходят до уровня исследуемого предприятия. Экспертами, оценивающими предлагаемые разработчиками формулировки, являются обычно сотрудники руководящего состава изучаемой и вышестоящей организации. Далее выявляются факторы, способствующие достижению цели. Фактически ими являются подцели, определяемые как следующий уровень ветвления дерева цели. Для промышленного предприятия, если целью является увеличение объема и повышение качества выпускаемой продукции, такими факторами могут быть совершенствование методов планирования и оперативного управления; улучшение использования оборудования и производственных мощностей; совершенствование производственной структуры; улучшение использования материалов; повышение квалификации персонала и совершенствование баланса рабочей силы и т.д.

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

Для вновь строящихся и реконструируемых предприятий в последнее время создают автоматизированные технологические комплексы. Благодаря развитию микропроцессорной техники системы управления в таких комплексах встраиваются непосредственно в технологическое оборудование, образуя единое целое. Естественно, что в разработке таких автоматизированных технологических комплексов участвуют на равных как конструторы и технологи, так и специалисты по управлению. Однако на более высоких уровнях управления разработчики АСУ исходят из уже принятой технологии.

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

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

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

3. Стадия разработки проектов

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

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

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

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

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

Обучение персонала проводится по группам - управленческого персонала методам управления в условиях функционирования АСУ и персонала эксплуатации новых технических средств - их обслуживанию.

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

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

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

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

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

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

Разработчик на этом этапе обязан завершить разработку программного обеспечения создаваемой АСУ, в первую очередь отладку и сдачу заказчику рабочих программ информационной базы или банка данных; для пакетов прикладных программ выполнить генерацию необходимых рабочих программ и их стыковку с другими программами; осуществлять методическое руководство и помощь заказчику по формированию и ведению информационной базы и по разработке должностных инструкций управленческому персоналу и работникам ВЦ; завершить разработку рабочей документации по всем видам обеспечения; осуществить поэтапную сдачу заказчику рабочих программ на контрольном примере, документации рабочего проекта с оформлением актов сдачи-приемки АСУ в опытную эксплуатацию. На этапе рабочего проектирования особенно возрастает значение согласования и координации деятельности всех участников разработки.

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

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

4. Стадия ввода в эксплуатацию

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

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

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

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

Разработчик на стадии ввода в эксплуатацию обязан по результатам опытной эксплуатации скорректировать техническую документацию; осуществлять методическое руководство и принимать участие в сдаче задач или комплексов задач в промышленную эксплуатацию; принимать участие в разработке программы приемо-сдаточных испытаний и в работе комиссии по приему АСУ в промышленную эксплуатацию.

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

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

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

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

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

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