Характеристики классов технологий проектирования
Класс технологии проектирования
| Степень автоматизации
| Степень типизации
| лапти
|
Каноническое проектирование
| Ручное проектирования
| Оригинальное проектирование
| Реконструкции
|
Индустриальное автоматизированное проектирование
| Компьютерное проектирование
| То же
| Реструктуризация модели
|
Индустриальное типовое проектирование
| То же
| Типовое сборочное проектирование
| Параметризация и реструктуризация модели
|
^ Каноническое проектированиеАПС ориентировано на использование главным образом каскадной модели жизненного цикла АИС.Стадии и этапы работы такого проектирования описаны
в ГОСТ 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 Engineering) — в дословном переводе — разработка программного обеспечения информационных систем при поддержке (с помощью) компьютера. В настоящее время не существует общепринятого определения CASE, термин CASE используется в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных автоматизированных информационных систем (АИС) в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки АИС.
©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.