Смекни!
smekni.com

Основные стадии создания автоматической системы управления (стр. 3 из 4)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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