Современные методы и средства проектирования информационных систем

Введение

Целью данного обзора является введение в особенности современных методов и средств проектирования информационных систем, основанных на использовании 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 расшифровывается как Computer -Aided Software Engineering , т.е. разработка ПО с помощью компьютера.

Изобразим ось времени, в качестве начальной точки возьмем 1965 год. Именно тогда начался период раннего внедрения компьютеров в бизнесе. В то время применялись в основном мэйнфреймы (mainframes) - большие ЭВМ коллективного пользования.

С 1970 по 1990 год мэйнфреймы доминировали на рынке. Мэйнфрейм в то время – это, прежде всего, IBM 360/370. Все данные хранились и обрабатывались на одной очень большой ЭВМ, пользователи работали за экранами терминалов, которые могли только отображать информацию, но никакой обработки не производили. В СССР скопировали мэйнфреймы под именем ЕС ЭВМ. Были клоны IBM 360/370 в Англии, ФРГ и Японии.

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

В середине 1990-х начинается адаптация Internet-систем, которые доминируют с середины 2000-го года. Сейчас начинают появляться новые системы, которым раньше не было аналогов; их принято называть "не ПК" (un-PC). В их число можно включить мобильные телефоны, карманные компьютеры, системы управления автомобилем (например, стоимость программного обеспечения автомобиля Ford уже превышает стоимость железа, из которого он сделан) и многое другое.

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

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

Посмотрим на эволюцию подхода к проектированию систем.

Развитие методологии проектирования

С середины 1960-х до середины 1970-х годов программы преимущественно писались по принципу RYO ( Roll Your Own), т. е. каждый писал так, как хотел и как умел - не было определенных подходов к процессу разработки ПО . В середине 70-х годов прошлого столетия возникла идея структурного программирования ( SDM , Structure Design Methodology ), происходит развитие методологии программирования и технологии моделирования. В Европе главным идеологом структурного программирования считается Дейкстра, а в США – ДеМарко. Разработчики приходят к пониманию, что систему (программу) можно описывать без использования конструкций языка программирования, а на более абстрактном уровне. В этот период времени программисты (и не только) поняли, что моделирование играет немаловажную роль, а вместе с ним и правила для моделирования. К этому моменту относится и введение блок-схем ( flow charts). Для этого этапа развития технологии моделирования характерно, что центром программного продукта является процесс, а не данные (для хранения данных использовались индексные файлы и иерархические базы данных ).

В середине 1980-х годов происходит очередной прорыв: появляются реляционные базы данных , один из авторов которых - James Martin . Главной частью программного продукта становятся данные и базы данных . Теоретиками была создана реляционная алгебра , ставшая основой для построения реляционных баз данных. Отсюда и новый подход к моделированию систем - IE ( Information Engineering - методы и средства проектирования прикладных и информационных программ), в которых за основу принимаются не процессы, а структуры обрабатываемых данных.

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

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

Главные составляющие CASE -продукта таковы:

  • методология (Method Diagrams) , которая задает единый графический язык и правила работы с ним. CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым, строгим, наглядным и интуитивно понятным графическим языком, позволяющим получать обозримые компоненты с простой и ясной структурой. При этом программы представляются двумерными диаграммами (которые проще в использовании, чем многостраничные описания), позволяющими заказчику участвовать в процессе разработки, а разработчикам - общаться с экспертами предметной области, разделять деятельность системных аналитиков, проектировщиков и программистов, облегчая им защиту проекта перед руководством, а также обеспечивая легкость сопровождения и внесения изменений в систему.
  • графические редакторы (Graphic Editors) , которые помогают рисовать диаграммы; возникли с распространением PC и GUI. Этими двумя составляющими (так называемые upper case технологии) CASE-технологии поначалу и были ограничены. Диаграммы стало легко рисовать, их появилось множество, но пользы от них было мало – проектирование было развито лишь на уровне рисования. Существовало много проблем: никто не знал все используемые в тот момент технологии (не мог писать и для мэйнфреймов, и для клиента, и для сервера); неясно было, как объединять написанное для разных платформ.
  • генератор : по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая low case часть CASE-технологии ). Генерация программ позволяет автоматически построить до 85-90% объектного кода или текстов на языках высокого уровня, но только для хорошо формализуемых частей программы (прежде всего, для описания баз данных и для задания форм ввода-вывода информации). Сложная обработка, как обычно, может быть описана с помощью ручного программирования.
  • репозиторий , своеобразная база данных для хранения результатов работы программистов (сложилась парадоксальная ситуация: к тому моменту базами данных пользовались все, кроме программистов), происходит переход от "плоских" файлов к системе хранения информации о разработке проекта.

Источник: CITFORUM

Александра Гнатуш

ЧТО?

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает:

  • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
  • средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
  • средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
  • средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
  • средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

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

  • средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
  • средства конфигурационного управления (PVCS (Intersolv));
  • средства тестирования (Quality Works (Segue Software));
  • средства документирования (SoDA (Rational Software)).

КОГДА?

Ввиду разнообразной природы 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-средствах можно проиллюстрировать следующей диаграммой (см. рис. 1).

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

Процесс оценки и выбора CASE-средств можно рассмотреть в виде модели. Этот процесс может преследовать несколько целей и включать:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

План перехода должен включать следующее:

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

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

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

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

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

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

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

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

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

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

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

Расшифровка аббревиатуры CASE: Computer Aided Software Engineering, что можно перевести на русский, примерно, как разработка программного обеспечения с помощью компьютера .

В соответствии с ГОСТ 19781-90 Программное обеспечение (ПО) – совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации.

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

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

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

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

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

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

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



Ø затяжной цикл и неудовлетворительные результаты тестирования.

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

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

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

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

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

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

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

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

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

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

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

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

3. Анализ производится сверху вниз, проектирование производится сверху вниз, разработка производится сверху вниз и тестирование производится сверху вниз.

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

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

Аббревиатура CASE расшифровывается как Computer Aided Software Engineering.

Case-studiеs - учебные конкретные ситуации специально разрабатываемые на основе фактического материала с целью последующего разбора на учебных занятиях. В ходе разбора ситуаций обучающиеся учатся действовать в «команде», проводить анализ и принимать управленческие решения. Название произошло от латинского термина «казус» -- запутанный или необычный случай. Главная особенность метода -- изучение студентами прецедентов, т.е. имевшихся в прошлом ситуаций из деловой практики.

Существуют различные обозначения этой технологии. В зарубежных публикациях можно встретить названия: метод изучения ситуации, метод деловых историй и, наконец, просто метод кейсов. В российских изданиях чаще всего говорится о методе анализа конкретных ситуаций (АКС), деловых ситуаций, кейс-методе, ситуационных задачах, а в 2001 году американские исследователи Эткинсона Дж., Уилсона Й. в своей книге: «Стратегический маркетинг. Ситуации. Примеры» ввели впервые понятие - «ситуационные задачи».

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

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

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

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

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

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

У метода 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 идет формирование проблемы и путей ее решения на основании кейса, который выступает одновременно в виде технического задания и источника информации для осознания вариантов эффективных действий.
  • 6. Метод case-study концентрирует в себе значительные достижения технологии «создания успеха». В нем предусматривается деятельность по активизации студентов, стимулирование их успеха, подчеркивание достижений обучаемых. Именно достижение успеха выступает одной из главных движущих сил метода, формирования устойчивой позитивной мотивации, наращивание познавательной активности.

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

Использование метода case-study имеет явные преимущества перед простым изложением материала, широко используемым в традиционной педагогике высшей школы России. Однако не стоит полагать, что кейсы могут заменить лекции. По мнению преподавателя Американского института бизнеса и экономики (AIBEc) в Москве Питера Эксмана нельзя тратить все свое время только на разбор конкретных примеров, потому что это формирует стереотипный, предвзятый подход к решению сходных проблем, и студент будет не в состоянии подняться на более высокий уровень обобщения. Кейсы показывают, как на практике применяются экономические теории; ценность таких упражнений, если они не имеют теоретической «начинки», невелика3.

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

Метод case-study относят к одному из «продвинутых» активных методов обучения. К преимуществам метода case-study можно отнести:

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

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

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

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

  • 1. Метод case-study необходимо как можно быстрее внедрить в программы подготовки специалистов по современным рыночным специальностям, в которых доминирует ситуационное знание и ситуационная деятельность, таким как менеджмент, экономика, социология, маркетинг и т.п.
  • 2. Активизировать использование метода case-study в системе дополнительного профессионального образования, особенно при реализации программ профессиональной переподготовки.
  • 3. Метод case-study необходимо использовать в органическом единстве с другими методами обучения, в том числе традиционными, закладывающими у студентов обязательное нормативное знание. Ситуационное обучение учит поиску и использованию знания в условиях динамичной ситуации, развивая гибкость, диалектичность мышления; чрезмерное увлечение ситуационным анализом может привести к тому, что будущий специалист окажется без необходимого «нормативного скелета», все его знания будет сводиться к знанию множества ситуаций без определенного методологического принципа или системы.
  • 4. Применение метода case-study должно быть методически обосновано и обеспечено. Это необходимо как на уровне организации учебного процесса по образовательной программе в целом, так и на уровне планирования его отдельным преподавателем. Необходима экспертная оценка специальностей, учебных дисциплин и их разделов, где применение метода case-study дает гораздо больший эффект, чем традиционные технологии обучения. Эти вопросы должны быть предметом обсуждения на методическом совете и являться целью повышения квалификации преподавателей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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