§2.4.3. Создания АИС и АИТ.

 

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

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

 

 

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

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

 

 

Установлены следующие стадии создания АИС (рис.26):

 

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

Документы:

  • бизнес-план,
  • технико-экономическое обоснование (ТЭО),
  • техническое задание (ТЗ)
 Документы:
  • технический проект (ТП) включая постановку задач (ПЗ),
  • рабочий проект (РП),
  • рабочая документация (РД) в составе руководства пользователя, руководства программиста…
 

Документы:

  • акты внедрения,
  • акты приемки-сдачи…
 

Документы:

  • приказы,
  • дополнительные соглашения с разработчиком,
  • дополнительные ТЗ

Рисунок 26. Жизненный цикл АИС.

 

 

Для поддержки проектных работ используются специальные CASE-технологии.

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

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

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

 

 

И в случае положительного заключения по вопросам целесообразности создания и возможностях финансирования разрабатывается ТЗ. ТЗ определяет идеологию будущей АИС.
Определяется в основном состав и структура разрабатываемой системы, т.е. из каких подсистем она состоит, как они связаны между собой, какие комплексы задач и в каком порядке будут разрабатываться, их назначение.
Также в ТЗ определяются основные показатели (параметры), которые должны быть достигнуты в условиях автоматизированного управления объектом, перечень функций управления с указанием входных и выходных документов, периодичность решения и формы представления информации для каждой функции.
Здесь же (в ТЗ) указываются все требования к программному, информационному, организационному и техническому обеспечению и составляется план-график совместных работ исполнителя и заказчика.
(Дополнительно о содержании ТЗ Вы можете узнать из следующего издания: Мамиконов А.Г. Проектирование АСУ: Учебник для спец. «АСУ» вузов. – М.: Высш.шк., 1987. – 303 с.: ил.)

 

 

Надо отметить что документы первого этапа проектирования выполняются в тесном контакте заказчика и разработчика. А написание ТЗ – это вообще обязанность заказчика, каковыми Вы и будете являться на своем рабочем месте. Другое дело, что разработчик способен и может помочь Вам в составлении этих документов.

На этапе проектирования на основе согласованного и утвержденного технического задания разрабатывается технический проект, а на его основе – рабочий проект, или единый технорабочий проект системы. Эти работы выполняет исполнитель, консультируясь с заказчиком.
(О том как составляется постановка задач в ТП Вы можете узнать из следующего издания: Автоматизированные информационные технологии в экономике: Учебник/ Под ред. Г.А.Титоренко. – М.: Компьютер, ЮНИТИ, 1998. – 400 с.)

Для реализации этапа внедрения заказчик должен проделать следующие работы по подготовки объекта к внедрению АИС.

 

 

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

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

 

 

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

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

 

 

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

Завершается опытная эксплуатация составлением акта о сдаче комплекса в промышленную эксплуатацию и ответственность за работу системы после этого несет заказчик.

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

 

Hosted by uCoz