Классификация технологий проектирования информационных систем.

В зависимости от степени компьютерной поддержки процесса проектирования выделяют канонические и индустриальные технологии проектирования.

Каноническое проектирование предполагает использование инструментальных средств универсальной компьютерной поддержки и предназначена для создания индивидуальных(оригинальных) проектов локальных ИС. При этом адаптация проектных решений возможна лишь путем перепрограммирования соответствуюших программных модулей.

Технологии индустриального проектирования использует инструментальные средства специальной компьютерной поддержки для разработки проектов сложных интегрированных(корпоративных) ИС.

Технологии индустриального проектирования подразделяются: типовые, автоматизированные.

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

По характеру адаптации проектные решения технологии типового проектирования можно разделить на 2 группы: параметрически – ориентированные и модельно – ориентированные.

Автоматизированной проектирование сохраняет преимущества индивидуального подхода к проектированию и при этом обеспечивает сокращение сроков и стоимости проектирования.

В зависимости от метода декомпозиции, ИС, выбранного при построении ее модели различают: Функционально – ориентированные и объектно – ориентированные технологии автоматического проектирования.

Стадии и этапы канонического проектирования информационных систем. Состав и содержание работ на стадиях. Итерационная модель проектирования информационных систем.

Идея деления процесса проектирования на стадии и этапы состоит в том, чтобы постепенно, проектируя «сверху - вниз» разрабатывать проектные решения сначало укрупнено, а затем детализировано. Процесс проектирования рекомендуется проводить в соответствии с ГОСТ 34.601-90 «Информационные технологии. Комплекс стандартов на АС. АС. Стадия создания». Указанный ГОСТ предлагает следующие 8 стадий процесса проектирования:

· формирование требований к АС (автоматизированной системе),

· разработка концепции АС,

· техническое задание,

· эскизный проект,

· технический проект,

· рабочая документация,

· ввод в действие,

· сопровождение АС.

Данный документ носит регламентационный характер.

В каноническом проектировании используется каскадная или итерационная модель создания ИС.

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

Следует обратить внимание на необходимость тщательной проработки начальных стадий проектирования. Факт: устранение ошибок при создании системы на стадии технического проекта стоит в 2 раза дороже, чем на предпроектной стадии, а на последующих стадиях в 10 раз и более.

Состав и содержание работ на стадиях:

1 стадия. Главное на этой стадии – провести предпроектное обследование и дать технико-экономическое обоснование целесообразности создания системы. Формируются требования к функциональной части, обеспечивающие подсистему, а также методу проектирования.

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

Стадия 3. Техническое задание – это итог предроектной работы по созданию ИС. Это документ, направленный от заказчика к исполнителю как задание. Главным здесь является состав функциональных задач будущей системы и требования к обеспечивающим системам. Главный документ формируется в соответствии с ГОСТ 34.602-89 «Техническое задание на создание АС».

Стадия 4. Ее цель – разработка предварительных решений. В экономических ИС применяется редко.

Стадия 5. Это основная стадия. Здесь уточняется состав и количество технических средств системы к узлам обработки данных. В части орг-го обеспечения предлагаются изменения в орг-ой структуре управления (пример: сливаются подразделения). В части инф-го обеспечения выбирается система классификации и кодирования, разрабатывается классификатор технико-экономической инф-ции; проектируется БД. Главное – алгоритмизация функциональных задач (не программирование). Разрабатываются формы документов, составляется план мероприятий по подготовке объекта к внедрению системы, проводится уточненный расчет ожидаемой экономической эффективности.

Стадия 6. Главное назначение – программирование или адаптация готовых программных средств. Здесь составляются технические инструкции, которые соответствуют должностным инструкциям, уточненным на стадии технического проектирования. При наличии проекта с-мы стадия техн-го проектирования. При наличии протатипа с-мы стадия технического проекта и рабочие документации объединяются в одну стадию – техно-рабочий проект.

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

Стадия 8. Цель сопровождения системы – поддержание эксплуатационных характеристик на проектом уровне. Сопровождение осуществляется исполнителем. Формы сопровождения: консультационная помощь, устранение недостатков, предложения по развитию ИС.

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

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

Можно выделить следующие основные принципы создания ИС на основе CASE – технологий:

1. принцип всесторонней компьютерной поддержки проектирования.

2. принцип модельного подхода. CASE – система может поддерживать методологию функционально –ориентированного или объектно-ориентированного подхода

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

4. принцип наглядности представления модели –означает наличие в составе CASE –технологий визуальных средств проектирования. Система графических изображения и правила, предназначенные для описания структуры системы, элементов данных и т.д., называются нотацией Case – средства.

5. принцип декомпозиции процесса ПИС с применением CASE –технологий на стадии и этапы.

Стадия 1. Анализ.

1.1 Предпроектные обследования подразделений организации

1.2 Разработка CASE-модели AS IS (как есть), отражающие существующие на момент обследования положения дел в организации и позволяющей понять, каким образом функционирует данная организация.

1.3 Анализ CASE -модели AS IS в целях выявления недостатков и выработки предложений по улучшению ситуаций

1.4 Разработка вариантов CASE -модели TO BE (как должно быть)

1.5 Выбор оптимального варианта CASE -модели TO BE в качестве тех. задания.

Стадия 2. Проектирование.

2.1Детализация иерархической модели ИС на основе функционально – ориентированного или объектно –ориентированного подхода

2.2 Разработка детализирующих моделей и диаграмм

2.3 Контроль проекта.

Стадия 3. Программирование

3.1 Коды генерации программного обеспечения

3.2 Генерация проектной документации

3.3Системное тестирование и отладка системы

3.4Обучение персонала

Стадия 4. Внедрение.

4.1Ввод в действие и сопровождение системы на основе CASE -модели.

6. принцип перенесение трудоемкости разработки на стадии анализа и проектирования

7. принцип независимости CASE -модели предметной области от средств реализации программирования. Благодаря соблюдению данного принципа имеется возможность переносить проектные решения с одной программы технической платформы на другую.

8. Возможность как прямого, так и обратного проектирования ИС. Обратное проектирование заключается в формировании модели и спецификацией (описание) на основе анализа программных кодов и схем БД.

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

Архитектура CASE-средства:

А) Репозиторий – специализированная БД проекта, предназначенная для отображения проектируемой ИС в каждый момент времени. Он содержит информацию:

1) о проектировщиках и их правах доступа

2) о организационных структурах

3) диаграммах и их компонентах

4) связях между диаграммами

5) о программных модулях и т.д.

Репозиторий обеспечивает резервные копирование проектных данных, хранение версий проекта, возможность коллективной

работы над проектом, контроль полноты и непротиворечивость данных.

Б) Средства контроля и сбора статистики выполняют функцию:

1) Выделение на диаграмме ошибочных элементов

2) мониторинг правильности построения диаграмм и выдачи сообщения об ошибках

3) сбор статистики об ошибках

В) Администратор проекта, предназначен для назначения или изменения прав доступа к репозиторию, мониторинга процесса проектирования и для выполнения других административных функций.

Г) Браузер позволяет просматривать диаграммы, переключаться между ними.

Можно привести много примеров различных классификаций CASE-средств, встречающихся в литературе. Остановимся на двух наиболее распространенных вариантах: по типам и категориям. Классификация по т и п а м отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ и включает следующие типы:

· средства анализа, предназначенные для построения и анализа моделей предметной области (Designer/IDEF; BP-win и ARIS).

· средства анализа и проектирования, поддерживающие наиболее распространенные методологии проектирования, которые используются для создания проектных спецификаций, в частности проектных компонентов интерфейсов системы, архитектуры системы, алгоритмов и структур данных: Vantage Team Builder, Designer/2000, Silverran, PRO-4, CASE-аналитик, ARIS.

· средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL — Structured Query Language — структурированном языке запросов) для наиболее распространенных СУБД: ER-win, S-Designer/2000, Data Base Designer, ARIS Tooleset.

· Средства разработки приложений и генераторы кода, входящая в состав Uniface, Jam, Power Builder, Developer/2000, Delphi и т.д.

· Средства реинжиниринга, обеспечивающие анализ программных кодов и схем БД и формирование на их основе различных моделей и проектных спецификаций: ER-win, Vantage.Team Builder, Silverran, PRO-4, ARIS Tooleset, Designer/2000 и т.д. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программы на языке C++, Rational Rose, Object Team.

Вспомогательные типы включают:

1) Средства планирования и управления проектом (Microsoft Project, SE Companion)

2) Средства конфигурационного управления (PVCS)

3) Средства тестирования (Quality Works)

4) Средства документирования (SoDa)

По степени интегрированности выделяют:

1) Локальные CASE-средства – применяются для анализа системы и разработки автоматизированных рабочих мест, поддерживают 1, 2 типа моделей и методов (CASE-аналитик, Design/IDEF)

2) Малые интегрированные CASE-средства, используются для создания небольших ИС, поддерживают несколько типов моделей и методов (ER-win, BP-win, , Silverran)

3) Средние интегрированные CASE-средства – поддерживают от 4-15 моделей и методов. В этой категории Rational Rose, Designer/2000.

4) Крупные интегрированные CASE-средства, поддерживаются свыше 15 типов моделей и методов. Пр-р: семейство программных продуктов ARIS.

Типовое проектирование информационных систем. Понятие, классификация, достоинства и недостатки типовых проектных решений. Параметрически-ориентированное и модельно-ориентированное типовое проектирование информационных систем: общая характеристика.

Методы типового проектирования ЭИС предполагают созда­ние системы из готовых типовых элементов (типовых проектных решений). Для реализации составных компонентов системы выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.

ТПР – тиражируемое проектное решение. Выделяют следующие классы ТПР:

· элементные ТПР – типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техни­ческому, математическому, организационному);

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

· объектные ТПР – типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

Каждое типовое решение предполагает наличие помимо функциональных решений еще и документации с детальным описанием типового проектного решения и процедур настройки. Достоинства и недостаткиТПР

Для реализации типового проектирования используются два подхо­да: параметрически-ориентированное и модельно-ориентированное проектирование.

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

Критерии оценки ППП делятся на следующие группы:

• назначение и возможности пакета;

• отличительные признаки и свойства пакета;

• требования к техническим и программным средствам;

• документация пакета;

• факторы финансового порядка;

• особенности установки пакета;

• особенности эксплуатации пакета;

• помощь поставщика по внедрению и поддержанию пакета;

• оценка качества пакета и опыт его использования;

• перспективы развития пакета.

Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.

Технология проектирования в этом случае должна обеспечивать еди­ные средства для работы как с моделью типовой ИС, так и с моделью кон­кретного предприятия.

Типовая ИС в специальной базе метаинформации — репозитории — содержит модель объекта автоматизации, на основе которой осуществля­ется конфигурирование программного обеспечения. Таким образом, мо­дельно-ориентированное проектирование ИС предполагает, прежде все­го, построение модели объекта автоматизации с использованием специ­ального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно так­же создание системы на базе типовой модели ИС из репозитория.

Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий.

Базовая модель ИС в репозиторий содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной струк­туры, которые поддерживаются программными модулями типовой ИС.

Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.

Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфиче­скими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате эксперт­ного опроса (SAP Business Engineering Workbench).

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

Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для полдержа­ния целостности создаваемой системы.

Модель бизнес-функций представляет собой иерархическую деком­позицию функциональной деятельности предприятия (подробное описа­ние см. в разделе «Анализ и моделирование функциональной области внедрения ИС»).

Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе «Спецификация функциональных требований к ИС»). Для отображения процессов используется модель управления событиями (ЕРС — Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей — приложений информационной системы в соответствии с характерными особенностя­ми конкретного предприятия.

Модели бизнес-объектов используются для интеграции приложе­ний, поддерживающих исполнение различных бизнес-процессов.

Модель организационной структуры предприятия представляет со­бой традиционную иерархическую структуру подчинения подразделений и персонала.

Внедрение типовой информационной системы начинается с анали­за требований к конкретной ИС, которые выявляются на основе резуль­татов предпроектного обследования объекта автоматизации

(см. раздел «Анализ и моделирование функциональной области внедрения ИС»). Для оценки соответствия этим требованиям программных продуктов может использоваться описанная выше методика опенки ППП. После выбора программного продукта на базе имеющихся в нем референтных моделей строится предварительная модель ИС, в которой отражаются все особен­ности реализации ИС для конкретного предприятия. Предварительная модель является основой для выбора типовой модели системы и опреде­ления перечня компонентов, которые будут реализованы с использовани­ем других программных средств или потребуют разработки с помощью имеющихся в составе типовой ИС инструментальных средств (например, АВАР в SAP, Tools в BAAN).

Реализация типового проекта предусматривает выполнение следую­щих операций:

• установку глобальных параметров системы;

• задание структуры объекта автоматизации;

• определение структуры основных данных;

• задание перечня реализуемых функций и процессов;

• описание интерфейсов;

• описание отчетов;

• настройку авторизации доступа;

• настройку системы архивирования.

7.Технико-экономическое обоснование проекта ИС: общая характеристика, состав и содержание. Техническое задание на разработку автоматизированной информационной системы: общая характеристика, типовые требования к содержанию и составу (ГОСТ 34.602-89).

Содержание технико-экономического обоснования проекта:

1. Должно быть четко сформулировано что получит заказчик, если согласиться финансировать проект.

2. Когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работы). В документе желательно отразить не только затраты на проект, но и выгоду при его использовании.

Ориентировачная структура документа

1) ограничения, риски, критические формы, которые могут повлиять на успешность проекта

2) совокупность усилий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал, пользователи системы

3) сроки завершения отдельных этапов, формы премки-сдачи работ, привлекаемые ресурсы.

Меры по защите информации

4) описание выполняемых системой функций

5) возможности развития системы

6) информационные объекты системы

7)интерфейсы и распределение функций между человеком и системой

8) требования к программным и информационным компонентам программы обеспечения

9) требования к системе упр. Б.д.

Состав и содержание технического задания (в соответствии с ГОСТ 34.602-89).

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

1. Общие сведения о проекте указывают:

А)полное наименование системы и ее условное обозначение. Шифр темы или номер договора, наименова­ние предприятия-разработчика и предприятия-заказчика.

Б) пере­чень документов, на основе которых создается система, плановые сроки начала и окончания работ по созданию системы, све­дения об источниках финансирования работ.

В) порядок оформления и предъявления заказчику результатов работ по созданию системы

2. Назначение, цели создания системы:

А) вид автоматизи­руемой деятельности

Б) перечень объектов автоматизации, на которых предполагается ее использовать;

В) наиме­нования и требуемые значения технических, технологических, производственно-экономических и других показателей объекта автоматизации, которые будут достигнуты в результате внедре­ния ЭИС.

3. Характеристика объекта автоматизации

сведения об условиях эксплуатации объекта и характеристиках окружаю­щей среды.

4. Требования к системе

А) требования к системе в целом;

- тре­бования к структуре и функционированию системы (перечень подсистем, уровни иерархии, степень централизации, способы Инф.обмена, режимы функционирования, взаимодействие со смежными системами, перспектива развития системы)

- требование к персоналу

- показатели назначения (степень адаптивности системы к изменениям процессов управления и знач.параметров)

- требование надежности и безопасности, эрганомики, к технич. обслуж. И т. Д.

Б)требования к функциональным подсистемам:

- перечень функций, задач или их комплексов, подлежащих автоматизации;

- временной регламент реализации каждой функции,

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

- перечень и критерии отказов в системе

В) Требования к видам обеспечения

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

- информационному (состав, структура и организация данных, обмен данными между компонентами системы, информационная совместимость со смежными с-ми, используемые классификаторы, СУБД, контроль данных и ведение информационных массивов, процедуры придания юрид-ой силы выходным документам)

- лингвистическому (используются языки программирования, языки взаимодействия пользователей системой, с-мы кодирования)

- программному ( независимость программных средств от платформы, качество прогр-ых и способы его контроля, использование фондов, алгоритмов и программ)

- организационному (стр-ра и ф-ции эксплуатируемых подразделений, защита от ошибочных действий персонала)

- также требования к техническому, методическому обеспе­чению ЭИС и др.

5. Состав и содержание работ по созданию системы должен содержать перечень стадий 4 этапов:

А) сроки выполнения;

Б) перечень организаций-исполнителей работ;

В) вид и порядок проведения экспертизы тех­нической документации

Г) программа и обеспечение надежности и др.

6. Порядок контроля приемки системы указыва­ют:

А)виды, состав, методы испытания системы и ее частей;

Б)общие требования к приемке работ по стадиям;

В) состав и статус приемочной комиссии.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

А) Преобразование входной информации к машиночитаемому виду

Б) Изменение в объекте автоматизации

В) сроки и порядок комплектования шта­тов и обучения персонала.

8. Требования к документированию приводят:

А) перечень подлежащих разработке комплектов и видов докумен­тов,

Б) Перечень документов на машинных носителях

9. Источники разработки

документы и информационные материалы на основе которой разрабатывается текст задания и сама система.

Для сложных ЭИС иногда на этой стадии включают третий этап -разработку «Эскизного проекта». На этапе «Эскизного проекта» сформулированные ранее требования служат основой для разработки предварительных решений по ЭИС в целом и от­дельным видам обеспечения. Эти решения прорабатываются на логическом уровне, включая алгоритмы обработки информации, описание информационных потребностей пользователей на уров­не названий документов и показателей.

Эскизный проект ИС. Технический проект ИС. Общая характеристика, состав и содержание.

Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям.

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

Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:

· функции ИС;

· функции подсистем, их цели и ожидаемый эффект от внедрения;

· состав комплексов задач и отдельных задач;

· концепция информационной базы и ее укрупненная структура;

· функции системы управления базой данных;

· состав вычислительной системы и других технических средств;

· функции и параметры основных программных средств.

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

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

На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.

Состав и содержание технического проекта приведены в таблице 3.2.

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

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

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

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

Для планирования проведения всех видов испытаний разрабатывается документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные примеры.

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

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

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

• ⇐ Назад
• 1
• 23