Главная Основные средства

Понятие жизненного цикла сложных систем. Жизненный цикл информационной системы

02.08.2019

Таблица 2.1

Определения.

1. Определение стандарта ISO/IEC 15288:2008 (Определение: life cycle -- evolution of a system, product, service, project or other human-made entity from conception through retirement (ISO 15288, 4.11):

жизненный цикл (ЖЦ) – это эволюция системы, продукции, услуги, проекта или иного рукотворного объекта от замысла до прекращения использования.

2. Определение стандарта ISO 15704 (Industrial automation systems - Requirements for enterprise-reference architectures and methodologies Системы промышленной автоматизации. Требования к архитектуре эталонных предприятий и методологии. Описывает эталонную архитектуру предприятия и средства реализации проектов в рамках полнрго жизненного цикла предприятия):

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

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

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

Комментарий: жизненный цикл – всегда жизненный цикл конкретной системы. Не бывает «жизненного цикла» кроме как в текстах стандартов, в жизни всегда «жизненный цикл X», где X – название целевой системы. Процессы жизненного цикла – это те процессы, которые акторы выполняют над/с системой, и которые меняют состояние системы, заставляя ее эволюционировать в ходе её жизненного цикла. «Управление жизненным циклом» -- общепринятое название подхода к описанию процессов жизненного цикла (а часто и название самой группы процессов жизненного цикла, описанных с использованием такого подхода).

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

Прежде всего, нужно различить жизненный цикл (иногда, ограничиваясь только инженерией, но не полным ЖЦ говорят также delivery process, изредка для софта -- software process) и другие "процессные представления" -- трансакции DEMO, логические "бизнес-процессы" (практики), workflows, проектные представления (подробнее -- http://ailev.livejournal.com/904643.html). Хотя есть множество подходов, при которых все эти разные аспекты описаний организации и методов ее работы смешиваются.

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

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

· «Нарезанная колбаска»

· V-диаграмма

Нарезанная колбаска".

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

Рисунок 2.1. Традиционное представление жизненного цикла

Вокруг традиционной «колбаски» могут указываться еще две дополнительных: как ЖЦ видят менеджеры (лица, управляющие проектом), и как ЖЦ видят инженеры(лица, реализующие проект) (рис.2.2)

Рисунок 2.2. Пример представления жизненного цикла

Жизненные циклы наблюдаются в историях отдельных товаров и потребностей, торговых марок, предприятий, целых индустрий и рынков. Жизненный цикл неотделим от конкретной системы, поэтому особенности разных систем порождают большое разнообразие экземпляров «колбасок» жизненных циклов (рис.2.3) .


Рис.2.3. Разнообразие жизненных циклов

1. Жизненный цикл ИС и его структура. 2

1.1 Стадии жизненного цикла ИС.. 3

1.2 Стандарты жизненного цикла ИС.. 4

2. Модели жизненного цикла. 6

2.1 Типы моделей жизненного цикла ИС.. 6

2.2 Достоинства и недостатки моделей жизненного цикла ИС.. 8

3. Процессы жизненного цикла ИС.............................................................. 11

3.1 Основные процессы жизненного цикла. 11

3.2 Вспомогательные процессы жизненного цикла. 13

3.3 Организационные процессы.. 14

Список использованной литературы.. 16


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

Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем.

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

Полный жизненный цикл информационной системы включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. В общем случае жизненный цикл можно в свою очередь разбить на ряд стадий. В принципе, это деление на стадии достаточно произвольно. Мы рассмотрим один из вариантов такого деления, предлагаемый корпорацией Rational Software – одной из ведущих фирм на рынке программного обеспечения средств разработки информационных систем (среди которых большой популярностью заслуженно пользуется универсальное CASE-средство Rational Rose).


1.1 Стадии жизненного цикла ИС

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

Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии.

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

1) Начальная стадия

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

2) Стадия уточнения

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

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

В конце стадии уточнения проводится анализ архитектурных решений и способов устранения главных факторов риска в проекте.

3) Стадия конструирования

На стадии конструирования разрабатывается законченное изделие, готовое к передаче пользователю.

По окончании этой стадии определяется работоспособность разработанного программного обеспечения.

4) Стадия передачи в эксплуатацию

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

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

1.2 Стандарты жизненного цикла ИС

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

Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

ISO/IEC 12207(International Organization of Standardization /International Electrotechnical Commission)1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последоват ельно дорабатываемых прототипов.


2. Модели жизненного цикла

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

Модель ЖЦ ИС включает в себя:

результаты выполнения работ на каждой стадии;

ключевые события - точки завершения работ и принятия решений.

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

2.1 Типы моделей жизненного цикла ИС

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

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

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

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

Рис. 2.1. Каскадная модель ЖЦ ИС

Рис. 2.2. Поэтапная модель с промежуточным контролем

Рис. 2.3. Спиральная модель ЖЦ ИС

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);

спиральная модель (характерна для периода после 1986.г.).

2.2 Достоинства и недостатки моделей жизненного цикла ИС

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

Лабораторная работа №1

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

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

Краткие теоретические сведения.

Жизненный цикл информационной системы

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

Жизненный цикл ИС –это непрерывный процесс с момента принятия решения о необходимости принятия решения о необходимости ее создания до полного завершения ее эксплуатации.

Процесс проектирования АИС регламентирован следующей документацией (стандартами, методологиями, моделями):

· ГОСТ 34.601-90. Введен в действие 01.01.1992. Устанавливает стадии и этапы создания автоматизированных систем и дает содержание работ на каждой стадии. Стадии и этапы работы, закрепленные в стандарте, соответствуют каскадной модели жизненного цикла.

· ISO/IEC 12207:1995. Международный стандарт, описывающий процессы жизненного цикла программного обеспечения. Содержит описание более, чем 220 базовых работ, выполнение которых может потребоваться в процессе создания ИС. Все процессы ЖЦ ПО подразделяются на три большие группы:

o Основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение);

o Вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, разрешение проблем, аудит, аттестация, совместная оценка, верификация);

o Организационные процессы (создание инфраструктуры, управление, обучение, усовершенствование).

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

o ISO/IEC TR 15271:1998 – руководство по применению ISO/IEC 12207;

o ISO/IEC TR 16326:1999 – руководство по управлению проектами при использовании ISO/IEC 12207.

· ISO/IEC 15288:2002. Международный стандарт, описывающий возможные процессы жизненного цикла систем, созданных человеком. Был создан с учетом опыта проектирования автоматизированных информационных систем, а также с привлечением специалистов различных областей: системной инженерии, программирования, администрирования, управления качеством, безопасностью и т.д. Предполагается, что стандарт содержит полное множество процессов, которые могут протекать в ходе жизненного цикла системы. Таким образом, задача разработчика ИС заключается в формировании необходимого ему множества – среды процессов. В обзоре стандарта отмечается, что в нем не содержится описания методов и процедур, необходимых для обеспечения выполнения целей, задач и результатов указанных процессов. В 2003 году выпущено руководство по применению стандарта (ISO/IEC TR 19760:2003). В настоящее время продолжается работа над подготовкой новой редакции стандарта серии 15288.

· Rational Unified Process (RUP) – концепция итеративной (спиральной) разработки программного обеспечения, предложенная фирмой Rational Software (ныне – подразделение IBM). Жизненный цикл ИС представляет собой четыре фазы: начало (inception), исследование (elaboration), конструирование (construction) и внедрение (transition). Каждая фаза может содержать в себе несколько итераций. Кроме того, завершение всех четырех фаз не всегда означает завершение работы над проектом – его развитие может продолжится новым циклом. В рамках итераций производится создание взаимосогласованных моделей, которые описываются на специально разработанном языке UML (Unified Modeling Language).

· Microsoft Solution Framework (MSF). Итерационная методология разработки приложений, аналогичная RUP. Так же включает четыре фазы: анализ, проектирование, разработка, стабилизация и предполагает использование объектно-ориентированного моделирования. По сравнению с RUP в большей степени ориентирована на разработку ИС для бизнеса.

· Extreme Programming (XP). Экстремальное программирование – это самая новая среди рассматриваемых методологий (первые идеи были сформированы в середине 1990-ых). Основные принципы: командная работа, эффективное взаимодействие между заказчиком и исполнителем в течение всего времени разработки ИС, использование последовательно дорабатываемых прототипов, достижение максимальной гибкости разработки (адаптация к изменяющимся требованиям заказчика).

Модели ЖЦ ИС.

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

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

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

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

I. Каскадная модель описывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970-80-х гг.

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

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

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

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

Третий этап - реализация проекта; по существу, разработка программного обеспечения (кодирование) в соответствии с проектными решениями предыдущего этапа. Методы реализации при этом принципиального значения не имеют. Результатом выполнения этапа является готовый программный продукт.

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

Последний этап - сдача готового проекта.

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

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

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


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

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

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

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

Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой:


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

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

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

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

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


©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27

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

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

Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения ( ПО ) первоначально, в 70-е годы прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации – серии ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно.

Процессы создания автоматизированных систем ( АС ), в состав которых входит и ПО , регламентированы стандартами ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания", ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы" и ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем". Однако многие положения этих стандартов устарели, а другие отражены недостаточно, чтобы их можно было применять для серьезных проектов создания ПС. Поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

В соответствии со стандартом ISO / IEC 12207 все процессы ЖЦ ПО разделены на три группы (рис.5.1).


Рис. 5.1.

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

5.2. Основные процессы ЖЦ ПС

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

  1. инициирование приобретения;
  2. подготовку заявочных предложений;
  3. подготовку и корректировку договора;
  4. надзор за деятельностью поставщика;
  5. приемку и завершение работ.

Инициирование приобретения включает следующие задачи:

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

Заявочные предложения должны содержать:

  1. требования, предъявляемые к системе;
  2. перечень программных продуктов;
  3. условия приобретения и соглашения;
  4. технические ограничения (например, по среде функционирования системы).

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

Подготовка и корректировка договора включает следующие задачи:

  1. определение заказчиком процедуры выбора поставщика, включающей критерии оценки предложений возможных поставщиков;
  2. выбор конкретного поставщика на основе анализа предложений;
  3. подготовку и заключение договора с поставщиком ;
  4. внесение изменений (при необходимости) в договор в процессе его выполнения.

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

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

  1. инициирование поставки;
  2. подготовку ответа на заявочные предложения;
  3. подготовку договора;
  4. планирование работ по договору;
  5. выполнение и контроль договорных работ и их оценку;
  6. поставку и завершение работ.

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

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

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

Процесс разработки включает следующие действия:

  1. подготовительную работу;
  2. анализ требований, предъявляемых к системе;
  3. проектирование архитектуры системы;
  4. анализ требований, предъявляемых к программному обеспечению;
  5. проектирование архитектуры программного обеспечения;
  6. детальное проектирование программного обеспечения;
  7. кодирование и тестирование программного обеспечения;
  8. интеграцию программного обеспечения;
  9. квалификационное тестирование программного обеспечения;
  10. интеграцию системы;
  11. квалификационное тестирование системы;
  12. установку программного обеспечения;
  13. приемку программного обеспечения.

Подготовительная работа начинается с выбора модели ЖЦ ПО , соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбирать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки , а также составить план выполнения работ .

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

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

Анализ требований к программному обеспечению предполагает определение следующих характеристик для каждого компонента ПО :

  1. функциональных возможностей, включая характеристики производительности и среды функционирования компонента;
  2. внешних интерфейсов;
  3. спецификаций надежности и безопасности;
  4. эргономических требований;
  5. требований к используемым данным;
  6. требований к установке и приемке;
  7. требований к пользовательской документации;
  8. требований к эксплуатации и сопровождению.

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

Проектирование архитектуры ПО включает следующие задачи для каждого компонента ПО :

  1. трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;
  2. разработку и документирование программных интерфейсов ПО и баз данных (БД);
  3. разработку предварительной версии пользовательской документации;
  4. разработку и документирование предварительных требований к тестам и плана интеграции ПО.

Детальное проектирование ПО включает следующие задачи:

  1. описание компонентов ПО и интерфейсов между ними на более низком уровне, достаточном для последующего кодирования и тестирования;
  2. разработку и документирование детального проекта базы данных;
  3. обновление (при необходимости) пользовательской документации;
  4. разработку и документирование требований к тестам и плана тестирования компонентов ПО;

Кодирование и тестирование ПО включает следующие задачи:

  1. кодирование и документирование каждого компонента ПО и базы данных, а также подготовку совокупности тестовых процедур и данных для их тестирования;
  2. тестирование каждого компонента ПО и БД на соответствие предъявляемым к ним требованиям с последующим документированием результатов тестирования;
  3. обновление документации (при необходимости);
  4. обновление плана интеграции ПО.

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

Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (

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

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

    1. планирование действий и работ, выполняемых в процессе эксплуатации, и установка эксплуатационных стандартов;
    2. определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.
  2. Эксплуатационное тестирование, осуществляемое для каждой очередной редакции программного продукта, после чего эта редакция передается в эксплуатацию.
  3. Собственно эксплуатация системы, которая выполняется в предназначенной для этого среде в соответствии с пользовательской документацией.
  4. анализ проблем и запросов на модификацию ПО (анализ сообщений о возникшей проблеме или запроса на модификацию, оценка масштаба, стоимости модификации, получаемого эффекта, оценка целесообразности модификации);
  5. модификацию ПО (внесение изменений в компоненты программного продукта и документацию в соответствии с правилами процесса разработки);
  6. проверку и приемку (в части целостности модифицируемой системы);
  7. перенос ПО в другую среду (конвертирование программ и данных, параллельная эксплуатация ПО в старой и новой среде в течение некоторого периода времени);
  8. снятие ПО с эксплуатации по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей. При этом программные продукты и документации подлежат архивированию в соответствии с договором.

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

Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы. Согласно данному стандарту структура жизненного цикла основывается на трех группах процессов:

1. основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

3. организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).

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

1. Разработка

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

1. оформление проектной и эксплуатационной документации;

2. подготовку материалов, необходимых для проведения тестирования тайных программных продуктов;

3. разработку материалов, необходимых для организации обучения персонала.

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

2. Эксплуатация

Эксплуатационные работы можно подразделить на подготовительные и основные. К подготовительным относятся:

1. конфигурирование базы данных и рабочих мест пользователей;

2. обеспечение пользователей эксплуатационной документацией;

3. обучение персонала.

Основные эксплуатационные работы включают;

1. непосредственно эксплуатацию;

2. локализацию проблем и устранение причин их возникновения;

3. модификацию программного обеспечения;

4. подготовку предложений по совершенствованию системы;

5. развитие и модернизацию системы.

3. Сопровождение

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



Модели жизненного цикла

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

К настоящему времени наибольшее распространение получили следующие основные модели жизненного цикла:

1. задачная модель;

2. каскадная модель (или системная) (70-85 г.г.);

3. спиральная модель (настоящее время).

Задачная модель

При разработке системы "снизу-вверх" от отдельных задач ко всей системе (задачная модель) единый поход к разработке неизбежно теряется, возникают проблемы при информационной стыковке отдельных компонентов. Как правило, по мере увеличения количества задач трудности нарастают, приходится постоянно изменять уже существующие программы и структуры данных. Скорость развития системы замедляется, что тормозит и развитие самой организации. Однако в отдельных случаях такая технология может оказаться целесообразной:

Крайняя срочность (надо чтобы хоть как-то задачи решались; потом придется все сделать заново);

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

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

Каскадная модель

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

Положительные стороны применения каскадного подхода заключаются в следующем:

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

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

Рис. . Каскадная схема разработки

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

Рис. 3. Реальный процесс разработки ПО по каскадной схеме

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

Спиральная модель

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

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

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

Рис 4. Спиральная модель ЖЦ ИС

Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

небольшую команду программистов (от 2 до 10 человек);

короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:

1. фаза определения требований и анализа;

2. фаза проектирования;

3. фаза реализации;

4. фаза внедрения.


Лекция 6. Классификация информационных систем

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

Классификация по масштабу

По масштабу информационные системы подразделяются на следующие группы:

1. одиночные;

2. групповые;

3. корпоративные.

Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создайся с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Microsoft Access.

Групповые информационные системы ориентированы на коллективное использова­ние информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (Называемые также SQL-серверами) для рабочих групп. Существует доволь­но большое количество различных SQL-серверов, как коммерческих, так и свобод­но распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать тер­риториально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура кли­ент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server.

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

Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре группы:

1. системы обработки транзакций;

2. системы принятия решений;

3. информационно-справочные системы;

4. офисные информационные системы.

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

Системы поддержки принятия решений - DSS (Decision Support Systeq) - пред­ставляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических и по другим показателям.

Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные систе­мы получили в сети Интернет.

Класс офисных информационных систем нацелен на перевод бумажных докумен­тов в электронный вид, автоматизацию делопроизводства и управление докумен­тооборотом.

Классификация по способу организации

По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы:

1. системы на основе архитектуры файл-сервер;

2. системы на основе архитектуры клиент-сервер;

3. системы на основе многоуровневой архитектуры;

4. системы на основе Интернет/интранет - технологий.

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

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-сервер­ных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, пони­мающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:

1. нижний уровень представляет собой приложения клиентов, имеющие программ­ный интерфейс для вызова приложения на среднем уровне;

2. средний уровень представляет собой сервер приложений;

3. верхний уровень представляет собой удаленный специализированный сервер базы данных.

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

В развитии технологии Интернет/интранет основной акцент пока что делается на разработке инструментальных программных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных и простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение Интернет/интранет-технологии с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер - сервер приложений - сервер баз данных - сервер динамических страниц - web-сервер.

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

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

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

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

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