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

решаются всего один раз, а затем теряют актуальность. Во-вторых, известно,

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

допуская детерминированную декомпозицию, трудно поддаются представлению в

форме задачи поиска в пространстве состояний, что затрудняет применение

моделей представления знаний с развитым аппаратом логического вывода. Этот

перечень можно продолжать. Кроме того, пожалуй, трудно назвать такую

управленческую область, где можно было бы найти идеального специалиста-

эксперта, который в принципе не допускал бы ошибок ни при каких

обстоятельствах и мог бы описать критерии поиска эффективного решения

управленческих задач. К тому же, часто встает вопрос, что следует повышать:

эффективность самого решения или эффективность процесса принятия решения.

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

называемый операциональный подход, аккумулирующий для решения задач

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

ситуационное управление, теорию принятия решений, методы математического

моделирования- теорию управления, а также эмпирический и эврисгическнй

подход. Это не значит, что организационное управление сводится к одной из

этих областей, а как раз то, что перечисленные методы и подходы применяются

постольку, поскольку представляются полезными для решения практических

задач. Как раз эта особенность и привлекает специалистов по

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

организационного управления, поскольку практически вся методология

искусственного интеллекта представляет как бы "втискивание" известных

методологий в рамки прагматического подхода для решения человеческих задач.

Кроме того, интеллектуальные системы могут разрешить также проблему

представления и использования нечеткой информации, которая наиболее

характерна для организационного управления.

По сути дела, направление на создание автоматизированных систем

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

управления, не было отмечено большими успехами именно в силу того, что во

время его расцвета - в 70-е годы - не был развит операциональный подход, а

методология искусственного интеллекта только зарождалась. Сложность

предметной области на том этапе не была преодолена, а понятие

Автоматической Системы Управления свелось, в результате, к понятию

автоматизированной информационно-справочной системы. Правда, положительным

результатом можно считать то, что были всесторонне обследованы многие сферы

организационного управления. Новый виток в этой области связывается с

созданием географических информационных систем. Но, как видно из

вышесказанного, применение ГИС само по себе не является панацеей. Ясно, что

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

общества и, в частности, управления, так как связана с инвентаризацией

информации (создание разного рода кадастров и т.п.). Но ГИС смогут

достаточно полно решать задачи поддержки принятия решений только при

интеграции с методологией создания интеллектуальных систем и другими

технологиями.

Методология создания экспертных систем в области управления должна

удовлетворять следующим требованиям:

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

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

каковыми являются управленческие системы;

поддерживать функции ЛПР как аккумулирующего, коммутирующею и

координирующего информационного центра;

поддерживать функции ЛПР по подготовке, принятию и исполнению решений;

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

информации;

использовать точные методы из теории управления и статистики, а также

разнообразные другие методы моделирования поведения объекта управления и

формирования решений;

интегрироваться с другими технологиями, такими как ГИС, базы данных и др.

Учитывая все перечисленные особенности, попробуем ответить на вопрос:

"В каких областях организационного управления и какие управленческие задачи

целесообразно решать с применением интеллектуальных систем?".

Очевидно, наиболее успешно и достаточно быстро можно создавать

интеллектуальные системы, если предметная область не слишком широка. В

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

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

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

примера можно привести проблему создания территориальных систем

экологического мониторинга. Ясно, что это одна из тех проблем, которые

декомпозируются по территориально-отраслевому принципу. Правда, остается

вопрос, с какого уровня и какой конкретной подзадачи начинать. К сожалению,

в наших условиях этот вопрос чаще всего решается с точки зрения наличия

финансового обеспечения.

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

наблюдается, если предметная область достаточно проста, но требуется

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

Примером могут служить экспертные системы для поддержки принятия решений в

кризисных ситуациях. Па первое место в таких задачах ставятся функции ЛПР

как координирующего информационного центра. Реализация этой функции

относительно несложна, но предполагает также попутное решение проблемы

поддержки средств автоматизации связи.

Большие преимущества применение технологий интеллектуальных систем

дает там, где область управления располагает большими объемами накопленной

информации - базами данных. Это дает возможность их обобщения и, например,

создания нейроэкспертной системы для решения задач планирования,

прогнозирования и т.п.

В качестве примеров конкретных интеллектуальных систем в области

организационного управления можно привести следующие. ЭС IМАСS помогает

руководителям промышленного производства в управлении делопроизводством,

планировании объема продукции, переучете товаров и др. (США). ЭС SmartSlim

- поддержка принятия управленческих решений в области маркетинга (США).

Интеллектуальная система формирует обычно один или несколько

вариантов решения в порядке предпочтения. Предлагаемые такой системой

рекомендации пользователь - лицо, принимающее решение, может либо принять,

либо отвергнуть, однако, за последствия несет ответственность он сам. При

этом преимущество интеллектуальной системы заключается в конструктивном

функциональном подходе к решению задач. Интеллектуальная система помогает

выполнить ЛПР его должностные функции.

Методология проектирования информационной системы

Жизненный цикл по ИС. Одним из базовых понятий методологии

проектирования информационных систем (ИС) является понятие жизненного цикла

ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс,

который начинается с момента принятия решения о необходимости его создания

и заканчивается в момент его полного изъятия из эксплуатации. Основным

нормативным документом, регламентирующим ЖЦ ПО, является международный

стандарт ISO/IEC 12207 (ISO - International Organization of Standardization

- Международная организация по стандартизации, IEC - International

Electrotechnical Commission - Международная комиссия по электротехнике). Он

определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые

должны быть выполнены во время создания ПО. Структура ЖЦ ПО по стандарту

ISO/IEC 12207 базируется на трех группах процессов:

основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация,

сопровождение);

вспомогательные процессы, обеспечивающие выполнение основных процессов

(документирование, управление конфигурацией, обеспечение качества,

верификация, аттестация, оценка, аудит, решение проблем);

организационные процессы (управление проектами, создание инфраструктуры

проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Разработка включает в себя все работы по созданию ПО и его компонент

в соответствии с заданными требованиями, включая оформление проектной и

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

проверки работоспособности и соответствующего качества программных

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

т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и

реализацию (программирование).

Эксплуатация включает в себя работы по внедрению компонентов ПО в

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

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

обучения персонала и т.д., и непосредственно эксплуатацию, в том числе

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

рамках установленного регламента, подготовку предложений по

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

Управление проектом связано с вопросами планирования и организации

работ, создания коллективов разработчиков и контроля за сроками и качеством

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

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

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

методов и средств испытаний ПО, обучение персонала и т.п. Обеспечение

качества проекта связано с проблемами верификации, проверки и тестирования

ПО. Верификация - это процесс определения того, отвечает ли текущее

состояние разработки, достигнутое на данном этапе, требованиям этого этапа.

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

требованиями. Проверка частично совпадает с тестированием, которое связано

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

оценкой соответствия характеристик ПО исходным требованиям. В процессе

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

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

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

поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы

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

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

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

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

конфигурацией позволяет организовать, систематически учитывать и

контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и

рекомендации конфигурационного учета, планирования и управления

конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

Каждый процесс характеризуется определенными задачами и методами их

решения, исходными данными, полученными на предыдущем этапе, и

результатами. Результатами анализа, в частности, являются функциональные

модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит

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

в проектных решениях, выработанных на более ранних этапах.

Модели жизненного цикла ПО. Стандарт ISO/IEC 12207 не предлагает

конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается

структура, определяющая последовательность выполнения и взаимосвязи

процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ

зависит от специфики ИС и специфики условий, в которых последняя создается

и функционирует). Его регламенты являются общими для любых моделей ЖЦ,

методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает

структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать

или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие

две основные модели ЖЦ:

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

спиральная модель (86-90 г.г.).

В изначально существовавших однородных ИС каждое приложение

представляло собой единое целое. Для разработки такого типа приложений

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

разбиение всей разработки на этапы, причем переход с одного этапа на

следующий происходит только после того, как будет полностью завершена

работа на текущем (рисунок 5). Каждый этап завершается выпуском полного

комплекта документации, достаточной для того, чтобы разработка могла быть

продолжена другой командой разработчиков.

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

следующем:

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

отвечающий критериям полноты и согласованности;

выполняемые в логичной последовательности этапы работ позволяют планировать

сроки завершения всех работ и соответствующие затраты.

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

Каскадный подход хорошо зарекомендовал себя при построении ИС, для

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

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

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

категорию попадают сложные расчетные системы, системы реального времени и

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

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

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

В процессе создания ПО постоянно возникала потребность в возврате к

предыдущим этапам и уточнении или пересмотре ранее принятых решений. В

результате реальный процесс создания ПО принимал следующий вид (рисунок 6):

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

Основным недостатком каскадного подхода является существенное

запаздывание с получением результатов. Согласование результатов с

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

каждого этапа работ, требования к ИС "заморожены" в виде технического

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

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

завершена. В случае неточного изложения требований или их изменения в

течение длительного периода создания ПО, пользователи получают систему, не

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

информационные) автоматизируемого объекта могут устареть одновременно с их

утверждением.

Для преодоления перечисленных проблем была предложена спиральная

модель ЖЦ (рисунок 7 , делающая упор на начальные этапы ЖЦ: анализ и

проектирование. На этих этапах реализуемость технических решений

проверяется путем создания прототипов. Каждый виток спирали соответствует

созданию фрагмента или версии ПО, на нем уточняются цели и характеристики

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

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

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

доводится до реализации.

Разработка итерациями отражает объективно существующий спиральный

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

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

текущем. При итеративном способе разработки недостающую работу можно будет

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

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

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

Основная проблема спирального цикла - определение момента перехода на

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

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

планом, даже если не вся запланированная работа закончена. План

составляется на основе статистических данных, полученных в предыдущих

проектах, и личного опыта разработчиков.

[pic]

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

Методологии и технологии проектирования ИС. Общие требования к

методологии и технологии. Методологии, технологии и инструментальные

средства проектирования (CASE-средства) составляют основу проекта любой ИС.

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

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

выполнение процессов ЖЦ.

Технология проектирования определяется как совокупность трех

составляющих:

пошаговой процедуры, определяющей последовательность технологических

операций проектирования;

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

технологических операций;

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

проектируемой системы.

Технологические инструкции, составляющие основное содержание

технологии, должны состоять из описания последовательности технологических

операций, условий, в зависимости от которых выполняется та или иная

операция, и описаний самих операций.

Технология проектирования, разработки и сопровождения ИС должна

удовлетворять следующим общим требованям:

технология должна поддерживать полный ЖЦ ПО;

технология должна обеспечивать гарантированное достижение целей разработки

ИС с заданным качеством и в установленное время;

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

виде подсистем (т.е. возможность декомпозиции проекта на составные части,

разрабатываемые группами исполнителей ограниченной численности с

последующей интеграцией составных частей). Опыт разработки крупных ИС

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

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

подсистем должна выполняться отдельными группами специалистов. При этом

необходимо обеспечить координацию ведения общего проекта и исключить

дублирование результатов работ каждой проектной группы, которое может

возникнуть в силу наличия общих данных и функций;

технология должна обеспечивать возможность ведения работ по проектированию

отдельных подсистем небольшими группами (3-7 человек). Это обусловлено

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

минимизации числа внешних связей;

технология должна обеспечивать минимальное время получения работоспособной

ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации

отдельных подсистем. Реализация ИС в целом в короткие сроки может

потребовать привлечения большого числа разработчиков, при этом эффект может

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

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

наличии полностью завершенного проекта, внедрение идет последовательно по

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10