Электронный офис

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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