• ×

    • Основные принципы Case-технологии. Факторы эффективности Case-технологии

    24.06.2019
    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. Спиральная модель ЖЦ 1.3. Методологии и технологии проектирования ИС 1.3.1. Общие требования к методологии и технологии

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

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

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

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

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

    Рис. 1.4. Представление технологической операции проектирования

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

    Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям:

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

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

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

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

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

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

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

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

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

    стандарт проектирования;

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

    стандарт пользовательского интерфейса.

    Стандарт проектирования должен устанавливать:

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

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

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

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

    Стандарт оформления проектной документации должен устанавливать:

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

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

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

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

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

    Стандарт интерфейса пользователя должен устанавливать:

    правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

    правила использования клавиатуры и мыши;

    правила оформления текстов помощи;

    перечень стандартных сообщений;

    правила обработки реакции пользователя. 1.3.2. Методология RAD

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

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

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

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

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

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

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

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

    фаза построения;

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

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

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

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

    общая информационная модель системы;

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

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

    построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

    определяется необходимость распределения данных;

    производится анализ использования данных;

    производится физическое проектирование базы данных;

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

    определяются способы увеличения производительности;

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

    Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

    Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

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

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

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

    Кейс-технология в образовании: общая характеристика

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

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

    Существующие обозначения рассматриваемой технологии

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

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

    Наши издания называют рассматриваемый метод следующим образом:

    • АКС (анализа конкретных ситуаций);
    • кейс-метод;
    • деловых ситуаций;
    • ситуационные задачи (впервые понятие ввели американские исследователи Й. Уилсон, Дж. Эткинсон в 2001 г.).

    Кейс-технология в образовании: что это такое?

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

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

    Что дает такой метод?

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

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

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

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

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

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

    Известно, что их шесть:

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

    Технологические особенности рассматриваемого метода

    Их также шесть:

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

    Рассматриваемая технология в рамках начальной школы

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

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

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

    Задания для квестов

    Они могут быть в виде:

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

    Освоение речевого этикета детьми посредством рассматриваемого метода

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

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

    Кейс-технологии в дошкольном образовании позволяют сформировать все 3 главных компонента речевого этикета:

    1. Овладение различными вариантами формул.
    2. Более подробное их «развертывание».
    3. Сопровождение формул доброжелательной интонацией, приветливой мимикой.

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

    Методы кейс-технологии

    Их шесть:

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

    CASE- технологии CASE (Computer Aided Software Engeneering) Эти технологии являются естественным продолжением эволюции всей отрасли разработки ПО. CASE-1: анализ требований, проектирование спецификаций и структуры, редактирование интерфейсов. CASE-2: генерация исходных текстов и реализация интегрированного окружения поддержки полного ЖЦ разработки ПО.










    Основные задачи CASE-систем 1.Разработка моделей предметной области, функциональной структуры системы, структур данных на графических языках. 2.Хранение моделей в единой базе данных – репозитории, доступном всем участникам разработки. 3.Формальный анализ разрабатываемых моделей, позволяющий избегать некоторых семантических ошибок. 4.Автоматизированная генерация структур баз данных, приложений, текстов программ. 5.Автоматизированная генерация документации на программные системы. 6.Обеспечение повторного использования наработок при модернизации, перепроектировании системы.




    Методологии структурного анализа классифицируются по признакам: по отношению к школам - Software Engineering (SE) и Information Engineering (IE); по порядку построения моделей - процедурно-ориентированные, ориентированные на данные и информационно-ориентированные; по типу целевых систем - для систем реального времени и для информационных систем.












    Классификация по функциональной ориентации Анализ и проектирование. CASE- аналитик (Эйтекс); POSE (Computer Systems Advisers); Design/IDEF (Meta Software); BPWin (Logic Works); SELECT (Select Software Tools); CASE/4/0 (micro TOOl GmbH) Проектирование баз данных и файлов. ERWin (Logic Works); S-Designor (SPD); Designtr/2000 (Oracle); Sillverrun (Computer Systems Advisers)/ Программирование. COBOL 2/Workbench (Mikro Focus); DECASE (DEC); NETRON/CAP (Netron); APS (Sage Softwfre). Сопровождение и реинжениринг Adpac CASE Tools (Adpac); Scan/COBOL и SuperStructure (Computer Data Systems): Inshtctor/Recoder (language Tecnologe).


    CASE-средства фирмы Computer Associated AllFusion Process Modeler (ранее:BPwin) - моделирование бизнес-процессовAllFusion Process Modeler (ранее:BPwin) AllFusion ERwin Data Modeler (ранее: ERwin) - моделирование данныхAllFusion ERwin Data Modeler (ранее: ERwin) AllFusion Data Model Validator (ранее: ERwin Examiner) - проверка моделей данных.AllFusion Data Model Validator (ранее: ERwin Examiner) AllFusion Model Manager (ранее: ModelMart) - сервер для совместной работы пользователей ERwin и/или BpwinAllFusion Model Manager (ранее: ModelMart) AllFusion Saphir Option - – средство просмотра структур данных широкого набора корпоративных информационных систем.AllFusion Saphir Option AllFusion Component Modeler (Paradigm Plus) - моделирование компонентов ПОAllFusion Component Modeler (Paradigm Plus)


    Альтернативой структурному подходу стали объектно-ориентированные методы разработки ИС. В первой половине 90-х годов был предложен универсальный язык объектного проектирования - Unified Modeling Language, UML (The Unified Method, Draft Edition (0.8). Rational Software Corporation, October 1995). Существует несколько CASE-средств, поддерживающих язык UML. Наиболее известными являются: CASE-средства, поддерживающие UML: Paradigm Plus фирмы PLATINUM technology (Computer Associated). Rational Rose фирмы Rational Software. SELECT фирмы SELECT Software






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


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


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


    Принципы организации RAD: Обязательное использование инструментальных средств. Тесное взаимодействие между разработчиками и заказчиком. Работа ведется немногочисленными хорошо управляемыми группами профессионалов. Разработка базируется на моделях. Итерационное прототипирование (традиционно 3 прототипа). RAD группа всегда работает только над одним прототипом. Большие системы разбиваются на подсистемы и для него выделяется несколько RAD групп.




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


    Принципы гибкой разработки ПО: 1. Мы придаем первоочередное значение удовлетворению заказчика, быстро и постоянно предоставляя нужное ему программное обеспечение. 2.Мы приветствуем изменения требований даже на поздних этапах разработки. Гибкие процессы позволяют поддерживать изменения, обеспечивая заказчику конкурентное преимущество. 3.Новые версии работающего ПО поставляются часто, с регулярностью от нескольких недель до нескольких месяцев, причем более предпочтительны короткие временные периоды. 4.В ходе проекта бизнесмены и разработчики должны постоянно работать вместе. 5.Проекты строятся мотивированными индивидуалами. Создайте им условия, удовлетворяйте их требования и доверяйте им в том, что касается выполнения работы. 6.Наиболее производительный и эффективный способ передачи информации рабочей группе и внутри нее – это разговор лицом к лицу. 7.Работающее ПО – это основной показатель прогресса. 8.Гибкие процессы стимулируют устойчивую работу. Спонсоры, разработчики и пользователи должны быть в состоянии неограниченно долго поддерживать постоянный ритм работы. 9.Непрерывное внимание к техническому качеству и хорошему проектированию улучшает гибкость. 10.Простота – искусство минимизировать количество ненужной работы – исключительно важна. 11.Наилучшим образом архитектура, требования и проектирование формируются и выполняются самоорганизующимися командами. 12.Команда должна регулярно обсуждать, как повысить эффективность своей работы, после чего изменять и согласовывать рабочий процесс с результатами этих обсуждений.


    Экстремальное программирование (XP) Ghbywbgs: Ищите самое простое решение, которое может сработать. Это вам не понадобится (не делать ничеговпрок). программный код должен быть максимально прост: –Система успешно проходит все тесты; –Код системы ясно раскрывает все изначальные замыслы; –В ней отсутствует дублирование кода; –Используется минимально возможное количество классов и методов

    Аббревиатура 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), при разборе которых от студентов требуется не только применить уже усвоенные теоретические знания и практические навыки, но и предложить нечто новое, при этом студенты и преподаватели выступают в роли исследователей.

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

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

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

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

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

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

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

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

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

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

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

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

    Расшифровка аббревиатуры 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-пакеты, не поддерживающие ни одной методологии (строго ориентированные средства управления проектом), а также средства, независимые от методологий (способные к адаптации к любым методам).

    Похожие статьи
     
    Категории
    Видеоматериалы
    Популярное
    Новое