CASE-технологии . Современные методы и средства проектирования информационных систем

А.М. Вендров

Аннотация

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

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

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

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

Введение

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


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

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

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

  • необходимость интеграции существующих и вновь разрабатываемых приложений;

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

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

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

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


  • неадекватная спецификация требований;

  • неспособность обнаруживать ошибки в проектных решениях;

  • низкое качество документации, снижающее эксплуатационные качества;

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

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

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


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

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

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

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:


  • CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

  • реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

  • широкое разнообразие качества и возможностей CASE-средств;

  • относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

  • широкое разнообразие в практике внедрения различных организаций;

  • отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

  • широкий диапазон предметных областей проектов;

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

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


  • Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

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

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

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


  • достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

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

  • отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;

  • CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;

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

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

Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:


  • высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

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

  • приемлемый уровень отдачи от инвестиций в CASE-средства.
^

1. Основы методологии проектирования ИС

1.1. Жизненный цикл по ИС

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:


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

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

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 .

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

1.2. Модели жизненного цикла ПО


Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

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


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

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

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


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

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

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

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

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

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

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

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

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

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

2.3. Моделирование потоков данных (процессов)


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

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


  • внешние сущности;

  • системы/подсистемы;

  • процессы;

  • накопители данных;

  • потоки данных.

^

4.2. Оценка и выбор CASE-средств

4.2.1. Общие сведения


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

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


  • оценка нескольких CASE-средств и выбор одного или более из них;

  • оценка одного или более CASE-средств и сохранение результатов для последующего использования;

  • выбор одного или более CASE-средств с использованием результатов предыдущих оценок.

Рис. 4.2. Модель процесса оценки и выбора

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


  • определение пользовательских потребностей;

  • цели и ограничения проекта;

  • данные о доступных CASE-средствах;

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

Элементы процесса включают:


  • цели, предположения и ограничения, которые могут уточняться в ходе процесса;

  • потребности пользователей, отражающие количественные и качественные требования пользователей к CASE-средствам;

  • критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе;

  • формализованные результаты оценок одного или более средств;

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

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

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


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

  • определение дополнительных критериев;

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

  • определение одной или более метрик для каждого критерия оценки;

  • назначение веса каждому критерию при выборе.

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

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

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

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



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

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

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

CASE-технология



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

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

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

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

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

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

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

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

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

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

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

Пользователи CASE-средств

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

Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

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

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

Метод case-study, или метод конкретных ситуаций (от англ, case - случай, ситуация), - метод активного проблемноситуационного анализа, основанный на обучении путем решения конкретных задач - ситуаций (решение кейсов).

Метод конкретных ситуаций (метод case-study) относится к неигровым имитационным активным методам.

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

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

В настоящее время сосуществуют две классические школы case-study - Гарвардская (американская) и Манчестерская (европейская). В рамках первой школы целью метода является обучение поиску единственно верного решения, вторая - предполагает многовариантность решения проблемы. Американские кейсы больше по объему (20-25 страниц текста плюс 8-10 страниц иллюстраций), европейские кейсы в 1,5-2 раза короче.

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

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

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

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

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

У метода case-study есть свои признаки и технологические особенности, позволяющие отличить его от других технологий.

Признаки метода case-study:

  • 1. Наличие модели социально-экономической системы, состояние которой рассматривается в некоторый дискретный момент времени.
  • 2. Коллективная выработка решений.
  • 3. Многоальтернативность решений; принципиальное отсутствие единственного решения.
  • 4. Единая цель при выработке решений.
  • 5. Наличие системы группового оценивания деятельности.
  • 6. Наличие управляемого эмоционального напряжения.

Технологические особенности метода case-study:

  • 1. Метод представляет собой специфическую разновидность исследовательской аналитической технологии, т. е. включает в себя операции исследовательского процесса, аналитические процедуры.
  • 2. Метод case-study выступает как технология коллективного взаимодействия, важнейшими составляющими которой выступают работа в группе (или подгруппах) и взаимный обмен информацией.
  • 3. Метод case-study можно рассматривать как синергетическую технологию, суть которой заключается в подготовке процедур погружения группы в ситуацию, формирования эффектов умножения знания, инсайтного озарения, обмена открытиями и т. п.
  • 4. Метод case-study интегрирует в себе технологии развивающего обучения, включая процедуры индивидуального, группового и коллективного развития, формирования многообразных личностных качеств.
  • 5. Метод case-study выступает как специфическая разновидность проектной технологии. В обычной проектной технологии идет процесс разрешения имеющейся проблемы посредством совместной деятельности, тогда как в методе case-study идет формирование проблемы и путей ее решения на основании кейса, который выступает одновременно в виде технического задания и источника информации для осознания вариантов эффективных действий.

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

  • - иллюстративные учебные ситуации - кейсы, цель которых - на определенном практическом примере обучить алгоритму принятия правильного решения в определенной ситуации;
  • - учебные ситуации - кейсы с формированием проблемы, в которых описывается ситуация в конкретный период времени, выявляются и четко формулируются проблемы; цель такого кейса - диагностирование ситуации и самостоятельное принятие решения по указанной проблеме;
  • - учебные ситуации - кейсы без формирования проблемы, в которых описывается более сложная, чем в предыдущем варианте, ситуация, где проблема четко не выявлена, а представлена в статистических данных, оценках общественного мнения, органов власти и т. д.; цель такого кейса - самостоятельно выявить проблему, указать альтернативные пути ее решения с анализом наличных ресурсов;
  • - прикладные упражнения, в которых описывается конкретная сложившаяся ситуация, предлагается найти пути выхода из нее; цель такого кейса - поиск путей решения проблемы.
  • 1. Практические кейсы. Данные кейсы как можно реальнее должны отражать вводимую ситуацию или случай. Это исторический источник, реальный документ, статистика в динамике данных, даже вещественный артефакт или комплекс приведенных источников - компонентов кейса. Это кейс моделирования реального события или кейс моделирования проблемы, которую надо решить. Целью данного кейса является отработка навыков преломления знаний и умений в постобразовательное, профессионально-деятельностное пространство реальной жизни.
  • 2. Обучающие кейсы. Основной задачей их выступает обучение. Однако степень реальности более сводится к типичным учебным ситуациям, в которых отрабатывается автоматизм навыков и способов поиска решений. В данных процессах важна отработка навыков синтеза, объединения частных случаев в типичные, закономерные с выделением общих признаковых элементов, причин и факторов, возможных последствий.
  • 3. Научно-исследовательские кейсы ориентированы на включение в исследовательскую деятельность, например, на основе изучения всей доступной информации и работ ряда авторов, реконструкции события, ситуации в комплексе, разработки тематического проекта локального, регионального типа и проч. В состав кейсов данного типа могут входить тексты ученых, работавших по данной исследовательской проблеме раннее, но использовавших иные подходы, источники или методы исследования.

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

  • -- обучающие анализу и оценке;
  • - обучающие решению проблем и принятию решений;
  • -- иллюстрирующие проблему, решение или концепцию в целом.

Заслуживает внимания классификация кейсов, приведенная Н. Федяниным и В. Давиденко, хорошо знакомыми с зарубежным опытом использования метода case-study:

  • -- структурированный (highly structured) кейс, в котором дается минимальное количество дополнительной информации; при работе с ним специалист должен применить определенную модель или формулу; у задач этого типа существует оптимальное решение;
  • - “маленькие наброски” (short vignetts), содержащие, как правило, от одной до десяти страниц текста и одну-две страницы приложений; они знакомят только с ключевыми понятиями;
  • - большие неструктурированные кейсы (long unstructured cases) объемом до 50 страниц - самый сложный из всех видов кейсов; информация в них дается очень подробная, в том числе и совершенно ненужная; самые необходимые для разбора сведения, наоборот, могут отсутствовать;
  • - первооткрывательские кейсы (ground breaking cases), при разборе которых от специалистов требуется не только применить уже усвоенные теоретические знания и практические навыки, но и предложить нечто новое.

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

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

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

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

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

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

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

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

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

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

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

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

Структура кейса и принципы его построения.

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

  • 1. Формирование дидактических целей кейса, формулирование целей и задач; выявление “зоны ответственности” за знания, умения и навыки специалистов.
  • 2. Определение проблемной ситуации.
  • 3. Построение программной карты кейса, состоящей из основных тезисов, которые необходимо воплотить в тексте.
  • 4. Поиск институциональной системы (фирма, организация, ведомство и т. д.), которая имеет непосредственное отношение к тезисам программной карты.
  • 5. Сбор информации в институциональной системе относительно тезисов программной карты кейса.
  • 6. Построение или выбор модели ситуации, которая отражает деятельность института; проверка ее соответствия реальности.
  • 7. Выбор жанра кейса.
  • 8. Написание текста кейса.
  • 9. Диагностика правильности и эффективности кейса; проведение методического учебного эксперимента, построенного по той или иной схеме, для выяснения эффективности данного кейса.
  • 10. Подготовка окончательного варианта кейса.
  • 11. Внедрение кейса в практику, а также его публикация с целью распространения; в том случае, если информация содержит данные по конкретной фирме, необходимо получить разрешение на публикацию.
  • 12. Подготовка методических рекомендаций по использованию кейса: разработка задания для специалистов и возможных вопросов для ведения дискуссии и презентации кейса, описание предполагаемых действий в момент обсуждения кейса.

Кейс должен:

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

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

Требования к формату и структуре кейса.

Сюжетная часть - описание ситуации, содержащее информацию, позволяющую понять окружение, при котором развивается ситуация, с указанием источника получения данных:

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

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

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

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

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

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

Виды анализа кейсов и решаемые задачи.

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

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

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

Причинно-следственный анализ основывается на причинности; ее основными понятиями выступают “причина” и “следствие”, которые описывают связь между явлениями. Технология причинно- следственного анализа включает в себя следующие шаги:

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

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

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

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

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

Ситуационный анализ имеет особое значение при использовании метода case-study. Данный вид анализа основывается на совокупности приемов и методов осмысления ситуации, ее структуры, определяющих ее факторов, тенденций развития и т. п. Ситуационный анализ основывается на термине “ситуация”, который является достаточно многозначным. Несмотря на многообразие понимания ситуации, можно выделить то общее, что свойственно различным концептуальным подходам. Прежде всего следует отметить, что ситуация является результатом социальных изменений, она вытекает из предыдущей ситуации и втекает в последующую ситуацию, т. е. она процессуальная. Удачность выбора ситуации определяется степенью ее соответствия изучаемому знанию, а также наличием в ней нестандартности, некоторой интриги, что придает ей интересность, побуждает исследовательскую мотивацию.

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

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

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

Задачи, решаемые в процессе реализации метода case- study:

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

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

Первый - знакомство с ситуацией, ее особенностями.

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

Третий - предложение концепций или тем для мозгового штурма.

Четвертый - анализ последствий принятия того или иного решения.

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

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

Бородкина Вероника Николаевна ,

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

ГБПОУ Профессионального училища №39

п. Центральный Хазан Иркутской области

Кейс-метод как современная образовательная технология

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

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

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

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

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

Кейс-технологии объединяют в себе одновременно и ролевые игры, и метод проектов, и ситуативный анализ .

Кейс-технология (кейс-метод) – это интерактивная технология обучения, на основе реальных или вымышленных ситуаций, направленная не столько на освоение знаний, сколько на формирование у учащихся новых качеств и умений. Главное её предназначение – развивать способность разрабатывать проблемы и находить их решение, учиться работать с информацией. При этом акцент делается не на получение готовых знаний, а на их выработку, на сотворчество учителя и ученика. [ 4, 12 ]

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

    метод ситуационного анализа (Метод анализа конкретных ситуаций, ситуационные задачи и упражнения; кейс-стадии)

    метод инцидента;

    метод ситуационно-ролевых игр;

    метод разбора деловой корреспонденции;

    игровое проектирование;

метод дискуссии

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

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

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

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

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

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

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

2. Использование «местного» материала, как источника формирования кейсов.

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

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

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

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

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

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

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

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

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

При составлении заданий целесообразно использовать несколько уровней сложности:

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

– Вторая степень сложности: есть практическая ситуация – найди её решение

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

– Третья степень сложности: есть практическая ситуация – определи проблему и найди пути решения.

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

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

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

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

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

Используемая литература

1. Козырева Л.Метод кейс-стади и его применение в процессе обучения учащихся. М.,«Просвещение»,2005.

2. Логунова Н.Обучение как общение и сотворчество//Высшее образование в России.2000.№3.

3.Метод case-study как современная технология ориентированного обучения: Реферативный обзор/Под ред. Комиссаровой. М.:Финансовая академия при правительстве РФ,2005.

4.Михайлова Е.А. Кейс и кейс-метод: процесс написания кейса. http://www.hr-training.net/statya/mihailova_1/shtml.

5.Михайлова Е. И. Кейс и кейс-метод: общие понятия. / Маркетинг, №1, 1999

6.Формирование универсальных учебных действий в основной школе: от действия к мысли /Под редакцией А.Г. Асмолова. М., «Просвещение»,2010. .