Здавалка
Главная | Обратная связь

Характеристики классов технологий проектирования



Класс технологии проектирования Степень автоматизации Степень типизации лапти
Каноническое проектирование Ручное проектирования Оригинальное проектирование Реконструкции
Индустриальное автоматизированное проектирование Компьютерное проектирование То же Реструктуризация модели
Индустриальное типовое проектирование То же Типовое сборочное проектирование Параметризация и реструктуризация модели


^ Каноническое проектированиеАПС ориентировано на использование главным образом каскадной модели жизненного цикла АИС.Стадии и этапы работы такого проектирования описаны
в ГОСТ 34.601 —90.

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

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

 

Сопровождение АИС:

  • выполнение работ в соответствии с гарантийными обязательствами;
  • послегарантийное обслуживание.


Рассмотрим специфику составляющих некоторых стадий подробнее.

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

Материалы, полученные в результате обследования, используются для:

 

  • обоснования разработки и поэтапного внедрения систем;
  • составления технического задания на разработку систем;
  • разработки технического и рабочего проектов систем.


На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ^ АИС и детальныйанализ деятельности организации.

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

 

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


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

 

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


При изучении каждой функциональной задачи управления
определяются:

 

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


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

 

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


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

На этапе обследования следует классифицировать планируемые функции системы по степени важности.

Один из возможных форматов представления такой классификации — MuSCoW [22].

Эта аббревиатура расшифровывается так:

 


  • Must have — необходимые функции;

  • Should have — желательные функции;

  • Could have – возможные функции;

  • Won’t have — отсутствующие функции.


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


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

 

  • модель «как есть» («а8 i») отражает существующие в организации бизнес-процессы;
  • модель «как должно быть» — отражает необходимые изменения бизнес-процессов с учетом внедрения АИС.
    Уже на этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач:
  • получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБд и т. п.;
  • разработки плана работ по обеспечению надежности АИС и ес тестирования.


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

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

Результаты обследования представляют объективную основу для формирования технического задания на АИС [16— 181.

^ Техническое задание— это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.

При разработке технического задания (ТЗ) необходимо решить следующие задачи:

 

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


Типовые требования к составу и содержанию технического задания приведены в таблице ниже:

 

 


^ ТаблицаСостав и содержание технического задания

(ГОСТ 34.602 – 89)

Раздел Содержание
Общие сведения Полное наименование системы и ее условное обозначение. Шифр темы или шифр (номер) договора. Наименование предприятий разработчика и заказчика системы, их реквизиты. Перечень документов, на основании которых создается ИС. Плановые сроки начала и окончания работ. Сведения об источниках и порядке финансирования работ. Порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств
Назначение и цели создания (развития) системы Вид автоматизируемой деятельности. Перечень объектов, на которых предполагается использование системы. Наименования и требуемые значения технических, технологических, производственно – экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС
Характеристика объектов автоматизации Краткие сведения об объекте автоматизации. Сведения об условиях эксплуатации и характеристиках окружающей среды
Требования к системе Требования к системе в целом:
  • требования к структуре и функционированию системы (перечень подсистем, уровни иерархии, степень централизации, способы информационного обмена, режимы функционирования, взаимодействие со смежными системами, перспективы развития системы);
  • требования к персоналу (численность пользователей, квалификация, режим работы, порядок подготовки);
  • показатели назначения (степень приспособляемости системы к изменениям процессов управления и значений параметров)
  • требования к надежности, безопасности, эргономике, транспортабельности. эксплуатации, техническому обслуживанию и ремонту, защите и сохранности информации, защите от внешних воздействий, к патентной чистоте, по стандартизации и унификации.
Требования к функциям (по подсистемам):
  • перечень подлежащих автоматизации задач;
  • временной регламент реализации каждой функции;
  • требования к качеству реализации каждой функции, к форме представления выходной информации, характеристики точности, достоверности выдачи результатов;
  • перечень и критерии отказов. Требования к видам обеспечения:
  • математическому (состав и область применения математических моделей и методов, типовых и разрабатываемых алгоритмов); информационному (состав, структура и организация данных, обмен данными между компонентами системы, информационная совместимость со смежными системами, используемые классификаторы, СУБО, контроль данных и ведение информационных массивов, процедуры придания юридической силы выходным документам);
  • лингвистическому (языки программирования языки взаимодействия пользователей с системой, системы кодирования, языки ввода-вывода);
  • программному (Независимость программных средств от платформы, качество программных средств и способы его контроля, использование фондов алгоритмов и программ);
  • техническому;
  • метрологическому;
  • организационному (структура и функции эксплуатирующих подразделений, защита от ошибочных действий персонала);
  • методическому (состав нормативно-технической документации)

 

CASE методы

 

За последние десятилетия сформировалось новое направление в программотехнике — CASE (Computer-Aided Software/System Engi­neering) — в дословном переводе — разработка программного обес­печения информационных систем при поддержке (с помощью) компьютера. В настоящее время не существует общепринятого оп­ределения CASE, термин CASE используется в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных автоматизированных информационных систем (АИС) в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживаю­щие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (при­ложений) и баз данных, генерацию кода, тестирование, документи­рование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами обра­зуют полную среду разработки АИС.

 







©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.