ГОСЫ. ГОСы. 76. каскадная модель жизненного цикла ис (основные этапы разработки по каскадной модели. Достоинства и недостатки каскадной модели)
 Скачать 5.37 Mb.
|
|
115. ОСНОВНЫЕ РАЗДЕЛЫ ТЕХНИЧЕСКОГО ЗАДАНИЯ СОГЛАСНО ГОСТ 34.602-89 Согласно ГОСТ 34.602-89 ТЗ должно содержать следующие разделы (приведены в сокращенном виде): 1. Общие сведения 1. полное наименование системы и ее условное обозначение; 2. шифр темы или шифр (номер) договора; 3. наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; 4. перечень документов, на основании которых создается система, кем и когда утверждены эти документы; 5. плановые сроки начала и окончания работы по созданию системы; 6. сведения об источниках и порядке финансирования работ; 7. порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы. 2. Назначение и цели создания системы 3. Характеристика объекта автоматизации 1. краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию; 2. сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды. 4. Требования к системе 1. Требования к системе в целом; 2. Требования к функциям (задачам), выполняемым системой; 3. Требования к видам обеспечения. 5. Состав и содержание работ по созданию системы 1. перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ; 2. вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт); 3. программа работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости); 4. перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организации-исполнителей (при необходимости). 6. Порядок контроля и приемки системы 1. виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему); 2. общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации; 3. статус приемочной комиссии (государственная, межведомственная, ведомственная). 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 1. приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ; 2. изменения, которые необходимо осуществить в объекте автоматизации; 3. создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ; 4. создание необходимых для функционирования системы подразделений и служб; 5. сроки и порядок комплектования штатов и обучения персонала. 8. Требования к документированию 1. согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и научно-технической документации отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации; 2. требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД; 3. при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов. 9. Источники разработки: документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы. 116. ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ. 1. Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.). При конкурсной организации работ варианты проекта ТЗ на АС рассматриваются заказчиком, который - либо выбирает предпочтительный, вариант, либо на основании сопоставительного анализа подготавливает с участием будущего разработчика АС окончательный вариант ТЗ на AC. 2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС, Работу по согласованию проекта ТЗ на AC осуществляют совместно разработчик ТЗ на АС и заказчик системы, каждый в организациях своего министерства (ведомства). 3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения). 4. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС. 5. Если при согласовании проекта ТЗ на АС возникли разногласия между разработчиком и заказчиком (или другими заинтересованными организациями), то составляется протокол разногласий (форма произвольная) и конкретное решение принимается в установленном порядке. 6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на этот документ. 7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы. 8. ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой нормоконтроля организации - разработчика ТЗ и, при необходимости, подвергнуто метрологической экспертизе. 9. Копии, утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы. 10. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС. 11. Изменения к ТЗ на АС не допускается утверждать после представления системы или ее очереди на приемо-сдаточные испытания. 12. Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии, с требованиями ГОСТ 2.501. 117. ОПРЕДЕЛЕНИЕ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА. ИНТЕЛЛЕКТУАЛЬНЫЕ ЗАДАЧИ. ПРИМЕРЫ ИНТЕЛЛЕКТУАЛЬНЫХ ЗАДАЧ И ИХ ХАРАКТЕРИСТИКИ. Искусственный интеллект – направление в науке и технике, ориентированное на создание программно-аппаратных средств, направленных на решение интеллектуальных задач, где логическая обработка преобладает над вычислительной. Интеллектуальные задачи – построены на особенностях работы человеческого мозга Примеры: • Поддержка принятия решения в условиях неопределенности • Задача распознавания образов, речи, текста, структур. • Управление роботами. 118. ИНТЕЛЛЕКТУАЛЬНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ. ОСНОВНЫЕ ФУНКЦИИ, ПРИСУЩИЕ ИИС. ОСНОВНЫЕ ОТЛИЧИЯ ИИС ОТ ОБЫЧНЫХ ПРОГРАММНЫХ СРЕДСТВ. Процесс проектирования ИИС связан с моделями представления и обработки знаний об окружающем мире. Под системой подразумевается совокупность взаимосвязанных между собой элементов, взаимодействующих с окружающей средой. Окружающая среда – сущности и отношения между ними, а фрагмент окружающей среды, который вычленяется в рамках теории ИИ, называется предметной областью. В ИИС рассматривается область решения интеллектуальных задач. Проблемная область – совокупность предметной области и задач. Важной проблемой при проектировании является передача понятий структуры (совокупности понятий предметной области, а так же способы и алгоритмы решения Интеллектуальных задач) от человека к компьютеру. Функции: Решение неформализованных задач Решение задач в условиях неопределенности (неточности, неполноты, неоднозначности) информации Эвристическое решение задач – разумное сокращение перебора в пространстве поиска решений ИС отличается от ИИС тем, что последняя имеет базу знаний. Отличительные особенности ИИС по сравнению с обычными ИС состоят в следующем: 1. Интерфейс с пользователем на естественном языке с использованием понятий, характерных для предметной области пользователя; 2. Способность объяснять свои действия и подсказывать пользователю, как правильно ввести показатели и как выбрать подходящие к его задаче параметры экономической модели; 3. База знаний; 4. Способность автоматического обнаружения закономерностей в ранее накопленных фактах и включения их в базу знаний. Основное отличие в том, что ИИС направлены на решение неформализованных задач, которые имеют свои особенности: не могут быть заданы только в числовой форме, цели не могут быть заданы только аналитической функцией, не существует алгоритм решения, или существует, но нельзя использовать из-за ограниченности ресурсов. 119. АРХИТЕКТУРА СТАТИЧЕСКИХ И ДИНАМИЧЕСКИХ ИИС. ОПИСАНИЕ ОСНОВНЫХ КОМПОНЕНТОВ ИИС. Статические ИИС Интеллектуально диалоговая система Расчетно-статическая  Экспертная система Не учитываются изменения окружающей среды Статические ЭС предназначены для решения задач с неизменяемыми в процессе решения данными и знаниями Динамические учитывают изменения окружающей среды, происходящие за время решения задачи Подсистема моделирования внешнего мира необходима для прогнозирования, анализа и адекватной оценки состояния внешней среды. Изменения окружения решаемой задачи требуют изменения хранимых в ЭС знаний, для того чтобы отразить временную логику происходящих в реальном мире событий. В настоящее время технология экспертных систем используется для решения различных типов задач (интерпретация, предсказание, диагностика, планирование, конструирование, контроль, отладка, инструктаж, управление) в самых разнообразных проблемных областях, таких, как финансы, нефтяная и газовая промышленность, энергетика, транспорт, фармацевтическое производство, космос, металлургия, горное дело, химия, образование, целлюлозно-бумажная промышленность, телекоммуникации и связь и др. 120. ОПРЕДЕЛЕНИЕ ЗНАНИЙ. ОТЛИЧИЯ ЗНАНИЙ ОТ ДАННЫХ. НЕ-ФАКТОРЫ ЗНАНИЙ. МЕТОДЫ ФОРМАЛИЗАЦИИ ЗНАНИЙ. Отличия знаний от данных: • Знания имеют более сложную структуру • В отличие от данных, знания обладают внутренней интерпретируемостью, т.е. возможностью хранения в памяти, совместно с элементами данных, избыточной системы имён • Обладают рекурсивной структурой, возможностью расчленения и объединения (принцип матрёшки) • Связанность единиц Знаний, т.е. возможность установления различных отношений, отражающих семантику и прагматику (отношение говорящего к тому, что он говорит). Связи отдельных фактов, а также отношений, отображающих их смысл в целом. • Наличие у Знаний семантического пространства с заданной метрикой, т.е. возможность определить близость информационной единицы Базы Знаний. • Активность знаний, возможность ставить и достигать цели, формировать мотивы поведения строить процедуры решения задач. • Функциональная целостность, т.е. возможность выбора желаемого результата, средства анализа достаточности полученного результата. Эти качественные свойства Знаний связаны со сложной природой Знаний, изучение которой происходит на междисциплинарном уровне. При попытке формализации знаний возникает ряд проблем типичных для Знаний. Это наличие Не-факторов Знаний. Например: использование в диалоговых индикаторах качественных характеристик (сильные боли, высокое давление), которые не могут быть однозначно определены (интерпретированы в силу своей размытости). • Субъективные знания Эксперта, которые обладают некоторой степенью неопределённости, могут быть выражены некоторым интервалом. • недоопределенность, неточность, неполнота, некорректность и др. Для построения моделей Знаний, содержащих не-факторы, предложены специальные подходы и математические аппараты. Формализовать знания можно с помощью нечётких множеств, деревьев, статистических описаний. Для формализации знаний применяются: формальные грамматики, логические модели (дедуктивные и индуктивные модели, псевдофизические логики и др.), сетевые (простые, иерархические, однородные и неоднородные, функциональные, семантические, фреймовые, сценарии и др.), продукционные. 121. КЛАССИФИКАЦИЯ МОДЕЛЕЙ ПРЕДСТАВЛЕНИЯ ЗНАНИЙ. ЛОГИЧЕСКИЕ МОДЕЛИ. ЛОГИКА ПРЕДИКАТОВ И ЕЕ ПРИМЕНЕНИЕ ПРИ ФОРМАЛИЗАЦИИ ЗНАНИЙ. ПРИМЕР. Классификация знаний: По глубине Поверхностные – совокупность эмпирических ассоциаций и причинно-следственных отношений между понятиями данной предметной области. Глубинные – абстракции, образы, аналогии в которых отражается понимание в данной предметной области и взаимосвязь с её отдельными понятиями. По жёсткости Жёсткие – позволяют получить однозначные решения, рекомендации. Лёгкие – допускают нечёткие решения, интервальные решения, Случайные значения. По функциям в ИИС Знания о процессах и алгоритмах решения интеллектуальных задач (использует Решатель) Знания о языке общения и способах диалога (Средства общения) Знания о способах предоставления и модификации Знаний в Базе Знаний (Компонент приобретения новых знаний) Знания о способах объяснения результатов (интерпретация знаний) Логическая (предикатная) модель представления знаний основана на алгебре высказываний и предикатов, на системе аксиом этой алгебры и ее правилах вывода. Из предикатных моделей наибольшее распространение получила модель предикатов первого порядка, базирующаяся на термах (аргументах предикатов - логических констант, переменных, функций), предикатах (выражениях с логическими операциями). В качестве базовой модели представления знаний для реализации синтеза сценариев на основе причинно-следственных связей может использоваться логика предикатов первого порядка. В простых случаях для представления знаний можно применять логику высказываний. Синтез сценария сводится к построению формальной порождающей грамматики на определенном множестве терминальных и нетерминальных символов. Синтаксису логики высказываний соответствует контекстно-свободная порождающая грамматика, которая описывается четверкой G = (V, Т, Р, S), где V— конечное множество нетерминальных символов; Т — конечное множество терминальных символов, не пересекающееся с V; Р - конечное множество правил продукций, записанных в виде нотаций Бэкуса и представляющих собой расшифровку нетерминальных символов грамматики логическими выражениями, содержащими символы из Т и V; S - начальный символ грамматики  122. ПРОДУКЦИОННАМ МОДЕЛЬ ПРЕДСТАВЛЕНИЯ ЗНАНИЙ. ПРИМЕРЫ ПРАВИЛ. Продукционная модель знания — модель, основанная на правилах, позволяет представить знание в виде предложений типа «Если (условие), то (действие)». Условие – образец для поиска в БЗ Действие – действия или операторы, выполняемые при успешном поиске Продукционная модель обладает тем недостатком, что при накоплении достаточно большого числа (порядка нескольких сотен) продукций они начинают противоречить друг другу. При использовании продукционной модели база знаний состоит из набора правил, Программа, управляющая перебором правил, называется машиной вывода. Чаще всего вывод бывает прямой (от данных к поиску цели) или обратный (от цели для ее подтверждения – к данным). Данные — это исходные факты, на основании которых запускается машина вывода. Если в памяти системы хранится некоторый набор продукций, то они образуют систему продукций. В системе продукций должны быть заданы специальные процедуры управления продукциями, с помощью которых происходит актуализация продукций и выполнение той или иной продукции из числа актуализированных. В состав системы продукций входит база правил (продукций), глобальная база данных и система управления. База правил – это область памяти, которая содержит совокупность знаний в форме правил вида ЕСЛИ – ТО. Приведем несколько примеров. база данных (рабочая память) — область памяти, содержащая фактические данные (факты). Система управления формирует заключения, используя базу правил и базу данных. В прямых выводах выбирается один из элементов данных, содержащихся в базе данных, и если при сопоставлении этот элемент согласуется с левой частью правила (посылкой), то из правила выводится соответствующее заключение и помещается в базу данных или исполняется действие, определяемое правилом, и соответствующим образом изменяется содержимое базы данных. В обратных выводах процесс начинается от поставленной цели. Если эта цель согласуется с правой частью правила (заключением), то посылка правила принимается за подцель или гипотезу. Этот процесс повторяется до тех пор, пока не будет получено совпадение подцели с данными. Пример. Имеется фрагмент базы знаний из двух правил: П1: Если (отдых – летом) и (человек – активный) то (ехать в горы) П2: Если (любит – солнце) то (отдых – летом) Предположим, в систему поступили данные — (человек¬ – активный) и (любит – солнце). Прямой вывод — исходя из данных, получить ответ. 1-й проход. Шаг 1. Пробуем П1, не работает (не хватает данных (отдых–летом)). Шаг 2. Пробуем П2, работает, в базу поступает факт (отдых–летом). 2-й проход. Шаг 3. Пробуем П1, работает, активируется цель (ехать в горы), которая и выступает как вывод. Обратный вывод — подтвердить выбранную цель при помощи имеющихся правил и данных. 1-й проход. Шаг 1. Цель — (ехать в горы): пробуем П1 — данных (отдых– летом) нет, они становятся новой целью, и ищется правило, где она в правой части. Шаг 2. Цель (отдых – летом): правило П2 подтверждает цель и активирует ее. 2-й проход. Шаг 3. Пробуем П1, подтверждается искомая цель. Продукционная модель привлекает разработчиков своей наглядностью, высокой модульностью, легкостью внесения дополнений и изменений и простотой механизма логического вывода. Сильные стороны систем продукций: • модульность; • единообразие структуры (основные компоненты продукционной системы могут применяться для построения интеллектуальных систем с различной проблемной ориентацией); • естественность (вывод заключения в продукционной системе во многом аналогичен процессу рассуждения эксперта); • гибкость родовидовой иерархии понятий, которая поддерживается только как связь между правилами (изменение правила ведет за собой изменение в иерархии); • простота создания и понимания отдельных правил; • простота пополнения и модификации; • простота механизма логического вывода. Слабые стороны систем продукций: • процесс вывода менее эффективен, чем в других системах, поскольку большая часть времени при выводе затрачивается на непроизводительную проверку применимости правил; • сложно представить родовидовую иерархию понятий; • неясность взаимных отношений правил; • сложность оценки целостного образа знаний; • отличие от человеческой структуры знаний; • отсутствие гибкости в логическом выводе. Представление знаний с помощью продукций иногда называют «плоским», так как в продукционных системах отсутствуют средства для установления иерархий правил. Объем знаний продукционных систем растет линейно, по мере включения в нее новых фрагментов знаний, в то время как в традиционных алгоритмических системах, использующих деревья решений, зависимость между объемом база знаний и количеством знаний является логарифмической. |