Case технологии курсовая работа

Использование CASE-технологий для создания систем управления электронного документооборота

КУРСОВАЯ РАБОТА

по дисциплине «Системы
управления электронным документооборотом»

на тему: Использование
CASE-технологий для создания систем управления электронного документооборота

Содержание

Введение

1. Анализ структуры и методологии современных case средств

1.1 Понятие термина — «CASE-средства»

1.2 Типовая структура CASE-средств

1.3 Эволюция развития CASE-технологий

1.4 Методологии проектирования, используемые в CASE-средствах

1.5 Методология CASE-средств объектно-ориентированного проектирования

1.6 Методология CASE-средств структурного проектирования

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

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

2.2 Классификация СУЭДО, созданных с помощью CASE-средств

2.3 Сравнительный анализ СУЭДО, созданных с помощью CASE-средств

Выводы

Перечень ссылок

Введение

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

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

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

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

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

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

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

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

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

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

К источникам, наиболее полно описывающим данную тему, можно
отнести [1, 2, 3, 5]. Технологии, используемые при создании СУЭДО, описаны в
источниках [13, 14, 16, 18].

Целью исследования курсовой работы является рассмотрение
методологии использования CASE-средств при создании СУЭДО.

Согласно цели поставлены следующие задачи:

. Провести анализ структуры и методологии CASE-средств.

. Рассмотреть типовую структуру современных CASE-средств.

. Рассмотреть эволюцию развития CASE-средств.

. Рассмотреть методологию CASE-средств объектного и
структурного моделирования.

. Провести сравнительный анализ и дать характеристику СУЕДО,
при создании которых использовались CASE-средства.

Для качественного решения поставленных задач при анализе
технологий современных CASE-средств и методик создания СУЕДО был использован
системный подход и метод сравнения. При исследовании источников по данной
проблематике и предметной области использовался метод системного анализа. При
рассмотрении принятых системных терминов по теме исследования использовался
терминологический подход и этимологический анализ понятий.

система управление электронный документооборот

1. Анализ
структуры и методологии современных case средств

1.1
Понятие термина — «CASE-средства»

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

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

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

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

1.2
Типовая структура CASE-средств

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

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

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

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

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

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

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

. Автоматизированная или автоматическая кодогенерация, для
различных платформ и различного вида кода: преобразования для получения
документации; формирования структуры БД, ввода/модификации данных; получения
выполняемых машинных кодов из спецификаций ПО; сборки модулей из словарей и
моделей данных и повторно используемых программ.

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

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

. Рентабельность.

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

В состав практически всех современных CASE-средств входят
следующие элементы [6]:

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

—       средства разработки приложений, с использованием
языков 4GL и генераторов кодов;

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

—       средства документирования;

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

—       средства реинжиниринга;

—       средства конфигурационного управления;

—       средства управления проектом.

1.3
Эволюция развития CASE-технологий

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

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

. Ассемблеров, дампов памяти, анализаторов;

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

. Символьных отладчиков, пакетов программ;

. Систем анализа и управления исходными текстами;

. CASE-средств генерации исходных текстов и реализации
интегрированного окружения поддержки полного жизненного цикла разработки ПО
(вторая генерация CASE-II)I является первой технологией, адресованной непосредственно
системным аналитикам и проектировщикам, и включающей средства для поддержки
графических моделей, проектирования спецификаций, экранных редакторов и
словарей данных. Она не предназначена для поддержки полного жизненного цикла и
концентрирует внимание на функциональных спецификациях и начальных шагах
проекта — системном анализе, определении требований, системном проектировании,
логическом проектировании БД [9].II отличается значительно более развитыми
возможностями, улучшенными характеристиками и исчерпывающим подходом к полному
жизненному циклу разрабатываемого ПО. В инструментарии CASE-II, в первую
очередь, используются средства поддержки автоматической кодогенерации, а также,
обеспечивается полная функциональная поддержка для выполнения графических
системных требований и спецификаций проектирования; контроля, анализа и
связывания системной информации и информации по управлению проектированием;
построение прототипов и моделей системы; тестирования, верификации и анализа
сгенерированных программ; генерации документов по проекту; контроля на
соответствие стандартам по всем этапам жизненного цикла. CASE-II может включать
свыше 100 функциональных компонент, поддерживающих все этапы жизненного цикла,
при этом пользователям предоставляется возможность выбора необходимых средств и
их интеграции в нужном составе [9].

1.4
Методологии проектирования, используемые в CASE-средствах

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

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

Основными стандартами методологий, реализованных в
CASE-средствах, являются:(Structured Analysis and Design Technique) —
методология структурного анализа и проектирования. Основана на понятиях
функционального моделирования. Отражает такие системные характеристики, как
управление, обратная связь и исполнитель;

IDEF0 (Integrated Definition Function Modeling) —
методология функционального моделирования. Используется для создания
функциональной модели, отображающей структуру и функции системы, а также потоки
информации и материальных объектов, преобразуемые этими функциями. Является
подмножеством методологии SADT; (DataFlow Diagram) — методология
моделирования потоков данных.

Рисунок 1.1 — Сравнение традиционной разработки и разработки
с использованием CASE-технологий

Следующие стандарты методологий применяются для описания
обмена данными между рабочими процессами: применяется для построения
информационной модели, отображающей структуру и содержание информационных
потоков, необходимых для поддержки функций системы;позволяет построить
динамическую модель меняющихся во времени поведения функций, информации и
ресурсов системы; — методология моделирования потоков работ. Является
более детальной по отношению к IDEF0 и DFD. Позволяет рассмотреть конкретный
процесс с учетом последовательности выполняемых операций. С помощью IDEF3
описываются сценарий и последовательность операций для каждого процесса;X
(IDEF1 Extended) — методология описания данных. Применяется для построения баз
данных. Относится к типу методологий «Сущность-связь» (ER —
Entity-Relationship) и, как правило, используется для моделирования реляционных
баз данных, имеющих отношение к рассматриваемой системе;-
объектно-ориентированная методология. Отражает взаимодействие объектов.
Позволяет наглядно отображать структуру объектов и заложенные принципы их
взаимодействия. Удобна для создания программных продуктов на
объектно-ориентированных языках; — методология онтологического
исследования сложных систем. С помощью методологии IDEF5 онтология системы
может быть описана при помощи определенного словаря терминов и правил, на
основании которых могут быть сформированы достоверные утверждения о состоянии
рассматриваемой системы в некоторый момент времени;- описывает бизнес-процесс в
виде потока последовательно выполняемых работ;- (Unified Modeling Language)
унифицированный язык моделирования, основанный на объектно-ориентированном
подходе. UML позволяют описать статическую структуру системы и ее динамическое
поведение в соответствующих нотациях.

В CASE-средствах широко используются методологии структурного
и объектно-ориентированного проектирования. Структурное проектирование основано
на алгоритмической декомпозиции, а объектно-ориентированное проектирование — на
объектно-ориентированной декомпозиции. Алгоритмическая декомпозиция позволяет
определить порядок происходящих событий. Объектно-ориентированная декомпозиция
позволяет определить иерархию классов объектов, их методы и свойства.
CASE-средства, поддерживающие объектно-ориентированное проектирование
используют методологию RUP (Rational Unified Process) и нотации языка UML.

1.5
Методология CASE-средств объектно-ориентированного проектирования

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

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

Буч отмечает также ряд следующих преимуществ
объектно-ориентированного подхода [7].

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

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

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

. Объектная модель позволяет в полной мере использовать
выразительные возможности объектных и объектно-ориентированных языков
программирования.

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

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

При переходе от структурного подхода к объектному, как при
всякой смене технологии, необходимо вкладывать деньги в приобретение новых
инструментальных средств. Здесь следует учесть и расходы на обучение (овладение
методом, инструментальными средствами и языком программирования). Для некоторых
организаций эти обстоятельства могут стать серьезными препятствиями.
Объектно-ориентированный подход не дает немедленной отдачи. Эффект от его
применения начинает сказываться после разработки двух-трех проектов и
накопления повторно используемых компонентов, отражающих типовые проектные
решения в данной области. Переход организации на объектно-ориентированную
технологию — это смена мировоззрения, а не просто изучение новых CASE-средств и
языков программирования [6].

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

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

Другой формой проявления взаимосвязи можно считать интеграцию
объектной и реляционной технологий. Реляционные СУБД являются на сегодняшний
день основным средством реализации крупномасштабных баз данных и хранилищ
данных. Причины этого очевидны: реляционная технология используется достаточно
долго, освоена огромным количеством пользователей и разработчиков, стала
промышленным стандартом, в нее вложены значительные средства и создано
множество корпоративных БД в самых различных отраслях, реляционная модель
проста и имеет строгое математическое основание; существует большое
разнообразие промышленных средств проектирования, реализации и эксплуатации
реляционных БД. Вследствие этого реляционные БД в основном используются для
хранения и поиска объектов в так называемых объектно-реляционных системах.
Объектно-ориентированное проектирование имеет точки соприкосновения с
реляционным проектированием. Например, как было отмечено выше, классы в
объектной модели могут некоторым образом соответствовать сущностям (в качестве
упражнения можно предложить детально проанализировать все сходства и различия
диаграмм «сущность-связь» и диаграмм классов). Как правило, такое
соответствие имеет место только на ранней стадии разработки системы — стадии
формирования требований. В дальнейшем, разумеется, цели
объектно-ориентированного проектирования (адекватное моделирование предметной
области в терминах взаимодействия объектов) и разработки реляционной БД
(нормализация данных) расходятся. Таким образом, единственно возможным
средством преодоления данного пробела является определение соответствия между
объектно-ориентированной и реляционной технологиями, которое в основном
сводится к отображению диаграмм классов и диаграмм «сущность — связь»
реляционной модели. Одним из примеров практической реализации взаимосвязи между
структурным и объектно-ориентированным подходом является программный интерфейс
(мост) между структурным CASE-средством Silverrun и объектно-ориентированным
CASE-средством Rational Rose, разработанный российской компанией
«Аргуссофт». Это ПО создает диаграммы классов Rational Rose на основе
RDM-модели (Relational Data Model — реляционная модель данных) Silverrun и
наоборот. Аналогичные интерфейсы существуют также между CASE-средствами ERwin
(с одной стороны), Rational Rose и Paradigm Plus (с другой стороны).

1.6
Методология CASE-средств структурного проектирования

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

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

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

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

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

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

—       принцип непротиворечивости — заключается в
обоснованности и согласованности использования элементов системы;

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

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

Каждой группе средств соответствуют определенные виды моделей
(диаграмм), наиболее распространенными из них являются следующие [6]:

—       SADT (Structured Analysis and Design Technique)
модели и соответствующие функциональные диаграммы;

—       DFD (Data Flow Diagrams) диаграммы потоков
данных;

—       ERD (Entity-Relationship
Diagrams) диаграммы «сущность-связь».

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

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

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

В Законе Украины «Об электронных документах и
электронном документообороте ст.5. дано такое определение термина
«электронный документ» — это документ, информация в котором
зафиксирована в виде электронных данных, включая обязательные реквизиты
документа [1]. Электронный документооборот — совокупность процессов создания,
обработки, отправки, передачи, получения, хранения, использования и уничтожения
электронных документов, которые выполняются с применением проверки целостности
и при необходимости с подтверждением факта получения таких документов.

Но использование электронного документооборота в
государственных учреждениях было бы невозможным, если не была определена
юридическая сила электронного документа. Эта сила электронному документу
предоставляется с помощью электронной подписи. Заслуга в этом в принятом Законе
Украины «Об электронных документах и ​​электронном
документообороте», в котором (согласно ст.6) определяется, что электронная
подпись является обязательным реквизитом электронного документа, который
используется для идентификации автора или лица, подписавшего документ.

Момент, с которого электронный документ приобретает
юридическую силу определен в Законе Украины «Об электронной цифровой
подписи» (п.2 ст.6) -«. наложением электронной подписи завершается
создание электронного документа». То есть юридическая сила устанавливается
с момента наложения электронной подписи.

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

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

Определим основные требования к системам электронного
документооборота:

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

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

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

. Открытость — система должна иметь открытые интерфейсы для
возможной доработки и интеграции с другими системами [3].

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

2.2
Классификация СУЭДО, созданных с помощью CASE-средств

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

Электронный документооборот обслуживается соответствующим
программным обеспечением (Enterprise Document Management Systems, EDMS). Схема
классификации СЭД изображена на рис.2.1.

Рисунок 2.1 — Классификация систем электронного
документооборота

Рассмотрим эти системы более подробно. СУЭДО, ориентированные
на бизнес-процессы (business-process EDM) строятся на основе концепции ECM.
Системы этого типа (EDMS) предназначены для специфических вертикальных и
горизонтальных приложений (иногда они имеют и отраслевое применение) [5].
EDMS-системы обеспечивают полный жизненный цикл работы с документами, включая
работу с образами, управления записями и потоками работ, управление содержимым
и др. EDMS-системы обеспечивают хранение и поиск 2-D документов в оригинальных
форматах (изображений, CAD-файлов, электронных таблиц и др.). C возможностью их
группировки в папки. Существует мнение некоторых отраслевых аналитиков, (в
зависимости от используемых схемы индексации и приложений) данный
документно-ориентированный подход может обеспечить в ряде EDMS-систем до 80%
функциональности PDM-системы при меньшей стоимости внедрения. Наиболее
известными разработчиками EDMS-систем являются компании Documentum (система
Documentum), FileNet (системы Panagon и Watermark), Hummingbird (система PC
DOCS) и др. Вендоры, больше других компаний преуспели в управлении содержимым
(например, компании Documentum и FileNet), сфокусировали свою деятельность на
реализации в СЭД таких функций, как управление шаблонами, управление
динамическими презентациями и публикация Web-содержимого. Cледует отметить, что
при том, что почти все EDMS-системы обеспечивают хороший уровень реализации
репозитариев и библиотечных сервисов для управления электронным содержанием
(например, образами и офисными документами), каждая из них наиболее сильна в
своей области. Например, в системах от компаний Open Text и iManage наиболее
хорошо проработаны управления офисными документами. В свою очередь, системы от
компаний Tower Technology, FileNet, IBM и Identitech особенно сильны в
управлении изображениями изделий большого объема.

Корпоративные СУЭДО (enterprise-centric EDM) обеспечивают
корпоративную инфраструктуру (доступную всем корпоративным пользователям) для
создания документов, коллективной работы над ними и их публикации. Базовые
функции корпоративных систем аналогичны функциям СУЭДО, ориентированным на
бизнес-процесс [5]. Как правило, корпоративные СУЭДО не ориентированы на
использование только в какой-то конкретной отрасли или на решение узкой задачи.
Они внедряются, как общекорпоративные технологии. Разработкой и продвижением
корпоративных СУЭДО занимаются компании Lotus (система Domino. Doc), Novell
(Novell GroupWise), Open Text (система LiveLink), Keyfile, Oracle (система Context),
iManage и др. Например, система Open
Text Livelink обеспечивает коллективную работу над документами по проекту для
внешних и внутренних пользователей, проведения онлайновых дискуссий,
распределенное планирование и маршрутизацию документов и др.

Системы управления потоками работ (Workflow Management
Systems) предназначены для обеспечения маршрутизации потоков работ любого типа
(определение путей маршрутизации файлов) в рамках корпоративных
структурированных и неструктурированных бизнес-процессов [2]. Они используются
для повышения эффективности и степени контролируемости корпоративных
бизнес-процессов. Системы управления потоками работ обычно покупаются, как
часть решения (например, EDMS-системы или PDM-системы). Здесь можно отметить
таких разработчиков, как компании Lotus (системы Domino / Notes и Domino
Workflow), Jetform, FileNet, Action Technologies, Staffware и др. Хороший
уровень управления потоками работ обеспечивают в своих решениях также компании
FileNet, IBM (через интеграцию с ПО MQ Series Workflow), Identitech, Tower
(через интеграцию с ПО Plexus и Staffware), Gauss (через интеграцию с ПО
Staffware) и др.

Системы управления вывода (Output Management Systems — OMS)
предназначены для генерации выходных документов. В некоторых OMS-системах
дополнительно реализованы также возможности архивации и длительного хранения
выходных отчетов и документов [7]. В связи с этим, многие из OMS-систем
классифицируются Gartner Group, как интегрированные системы архивации и поиска
документов (IDARS — Integrated Document Archive and Retrieval Systems). Однако
главной причиной популярности OMS-систем все же есть занимаемая ими рыночная
ниша — генерация документов и отчетов в информационных системах предприятий и
организаций, построенных с использованием ERP-систем. По мнению аналитиков
Gartner Group, одним из слабых мест современных ERP-систем является именно
плохое управление генерацией выходных документов (Разработчики ERP-систем больше
сосредоточены на повышении функциональности ключевых модулей своего ПО, чем на
«второстепенных» вопросах обеспечения генерации выходных отчетов, не
имеющих, по их мнению, хороших рыночных перспектив). Этот недостаток ERP-систем
и послужил основным фактором появления и быстрого развития рынка OMS-систем.
Ряд OMS-систем отвечает только за распределение и доставку выходных документов
(в электронном виде — в форматах HTML, XML и PDF). Очень часто OMS-системы
интегрированы с программными пакетами сканирования документов и изображений.
Полезной возможностью некоторых OMS-систем является и взаимодействие с
унаследованными корпоративными системами.

С помощью системы управления изображениями / образами
(Imaging Systems) осуществляется конвертация отсканированной с бумажных
носителей информации в электронную форму (обычно в формате TIFF). Данная
технология лежит в основе перевода в электронную форму информации по всем
унаследованных бумажных документов и микрофильмов. В число базовых функций
стандартной системы обработки изображений входят: сканирование, хранение, ряд
возможностей по поиску изображений и др.

2.3
Сравнительный анализ СУЭДО, созданных с помощью CASE-средств

В Украине сейчас широко представлены три класса СУЭДО:

) системы, разработанные российскими фирмами на базе
промышленных СУБД («Дело» компании «Электронные офисные
системы», LanDocs от Ланит, OPTIMA-WorkFlow производства
«Оптимы», «Кодекс» Центра компьютерных разработок,
«Золушка» Научно-технологического центра Института развития Москвы и
др.);

) русифицированные версии популярного ПО развитых стран
(Documentum 4i компании Documentum, DOCS Open фирмы Hummindbird, Lotus Domino /
Notes корпорации IBM, DocuLive концерна Siemens и т.д.) [3];

) системы, созданные российскими фирмами на платформе Lotus
Notes (CompanyMedia компании «ИнтерТраст», «БОСС-Референт»
фирмы «АйТи», «Эскада» от «Интерпроком ЛАН» и
др.).

Рассмотрим несколько из наиболее распространенных систем.
Система «БОСС-Референт» ориентирована на совместную работу многих
пользователей и создает внутри организации единое информационное пространство.
Построена на платформе IBM Lotus Domino / Notes и характеризуется следующими
свойствами:

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

—       поддержка сложных маршрутов согласования
документов;

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

—       удобство администрирования, масштабирования,
Web-доступ;

—       наличие средств защиты информации;

—       простота освоения пользователями.

СУЭДО «ДЕЛО» полностью поддерживает отечественные
традиции делопроизводства и полный жизненный цикл документа. Система может
использоваться и небольшими организациями — для автоматизации бумажного
документооборота, и крупными предприятиями — для организации электронного
документооборота.

Основные функции системы [6]:

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

—       управление прохождением документов с множеством
решений;

—       передачи завизированных документов сотрудникам на
ознакомление и исполнение;

—       контроль прохождения и исполнения документов;

—       обеспечение информационной безопасности.

СУЭДО «Евфрат-документооборот» со своими
функциональными возможностями рекомендована широкому кругу организаций. На
сайте компании говорится, что система может использоваться для предприятий
малого и среднего бизнеса. «Евфрат» построен в парадигме
«Рабочего стола» с папками. Документы раскладываются в папки, которые
могут иметь любую степень вложенности. Система позволяет выполнять следующие
задачи:

—       автоматизация канцелярии;

—       электронный архив документов;

—       корпоративный электронный документооборот
(workflow).

Система «OPTИMA-WorkFlow» предназначена для
формализации типовых процедур работы с документами (потоков работ) в
организациях, где такая работа является ежедневной практикой [7]. Система
автоматизирует процессы регистрации документов по правилам делопроизводства,
реализует механизмы аннотирования и сбора резолюций, доставки отчетов об
исполнении поручений. Функциональные возможности системы OPTИMA-WorkFlow:

—       полная функциональная маршрутизация со средствами
описания сценариев движения документов;

—       контроль соблюдения требований технологии работы
с документами;

—       контроль исполнения поручений; динамическая
модификация формы и содержания;

—       учет данных и процедур регистрации;

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

—       работа с любыми электронными объектами;

—       работа в распределенных корпоративных сетях;

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

Система «Megapolis — Документооборот» является
комплексным программным решением для создания систем управления документами и
автоматизации деловых процессов [8]. Система охватывает все этапы жизненного
цикла документов. Система имеет модули, ориентированные на автоматизацию
традиционных отечественных процессов делопроизводства и контроля
исполнительской дисциплины, характеризуется открытостью, высоким уровнем
расширения, адаптации и может использоваться в различных структурах — от
коммерческих компаний в органы государственной власти.

Система «Megapolis — Документооборот» предназначена
для решения следующих задач:

—       обеспечение автоматизации деловых процессов
(workflow);

—       организация общего информационного пространства
для организации с распределенной структурой;

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

—       организация работы с обращениями граждан;

—       формирование различных видов статистической и
аналитической отчетности.

По данным отчета IDC по европейскому рынку систем управления
документами, лидером была «Documentum 4i» — 11,1% рынка. Далее за ней
следовали (из систем, представленных в Украине) Lotus (только Domino. Doc) — 4%
и DOCS Open — 3%.

Посетители выставки «Управление 2000» в ходе опроса
на первую позицию поставили продукты «Lotus Notes» и
«Дело». Наиболее популярными системи на рынке являются: «Дело»,
«Documentum 4i», «CompanyMedia», «БОСС-Референт»
и «LanDocs». Они не претендует ни на полноту, ни на исчерпывающий
анализ рынка и характеристик сравниваемых систем. Все они постоянно развиваются
и совершенствуются, и отсутствие тех или иных свойств не является окончательным
приговором.

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

Выводы

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

Анализ и характеристика используемых методологий позволяет
сделать вывод, что в общем случае CASE-средство поддерживает метод
моделирования и его нотацию, которые совместно образуют стандарт. На
сегодняшний момент существуют два метода моделирования, применяемые в
CASE-средствах. Это методы объектно-ориентированного и структурного
проектирования. CASE-средства, поддерживающие объектно-ориентированное
проектирование используют методологию RUP (Rational Unified Process) и нотацию языка UML. CASE-средства,
поддерживающие структурное проектирование используют целый набор методик,
объединяемых общей аббревиатурой IDEF (Integrated Definition Function Modeling
— объединение методологических понятий). Для построения информационных моделей,
представляющих собой структурированную информацию (базы данных) применяются две
методологии: IDEF1 (Information Modeling — информационное моделирование) и IDEF1Х (IDEF1 eXtended) — ее расширенная
версия, которая использует в качестве средства моделирования диаграммы
«сущность-связь» (ERD — Entity-Relationship Diagram) и, как правило,
используется для моделирования реляционных баз данных.

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

Перечень
ссылок

1.
Закон
України «Про електронні документи та електронний документообіг» //
Відомості Верховної Ради України. — 2003. — N 851. — Ст.25.

2.
Вендров, А.М. Проектирование программного обеспечения экономических
информационных систем [Текст]: Учебник. — 2-е изд., перераб. и доп. / А.М.
Вендров. — М.: Финансы и статистика, 2006. — 544 с: ил.

.
Гринберг А.С., Король И.А. Информационный менеджмент:

Учеб.
пособие для вузов. [Текст] / А.С. Гринберг., И.А. Король. — М.: ЮНИТИ-ДАНА,
2011. — 415 с.

.
Долженкова М.Л. Использование CASE-средств для проектирования информационных
систем [Текст]: Учебное пособие / М.Л. Долженкова, О.В. Караваева — Киров:
Изд-во ВятГУ, 2011. — 73 с.

.
Матвієнко, О. Основи організації електронного документообігу [Текст]: навч.
посіб. / О. Матвієнко. — К.: ЦУЛ, 2008. — 112 с.

6. Моделирование
и реорганизация процессов [Електронний ресурс] / Режим доступу:
<http://www/>. big. spb.ru — Загол. з екрану

7.
Смірнова, Г.М. Електронні системи управління документообігом [Текст]: навч.
посіб. / Г.М. Матвієнко. — М.: МДУЕСІ, 2003. — 167 с.

.
Степанов.А. Г, Осипова. Т.Ф. Использование CASE-средств при описании
бизнес-процессов [Текст]: Учебник. / А.Г. Степанов., Т.Ф. Осипова. —
Санкт-Петербург: Уч-изд. СПГУАП, 2005. — 41 с: ил.

.
Кузнєцова, Т.В. Діловодство. Документаційне забезпечення уп — равління.
[Текст]: навч. посіб. / Т.В. Кузнєцова. — М.: ЗАО «Бізнес-школа
«Інтел-Синтез», 2000. — 320 с.

.
Кулешов, С.Г. Управлінське документознавство [Текст]: навч. посіб. / С.Г.
Кулешов. — К.: ДАКККІМ, 2003. — 57 с.

.
Тоискин, В.С. Автоматизация процессов проектирования на основе CASE технологий.
[Текст]: навч. посіб. / В.С. Тоискин., В.В. Красильников., В.В. Малиатаки. —
Ставрополь: Изд-во СГПИ, 2010. — 131 с.

.
Файзрахманов Р.А., Селезнев К.А. Структурно функциональный подход к
проектированию информационных технологий и автоматизированных систем с
использованием CASE-средств. [Текст] / Учебное пособие к практическим занятиям.
/ Р.А. Файзрахманов., К.А. Селезнев. — Пермь: Перм. гос. техн. ун-т, 2005. —
245 с.

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

Введение

Целью данного обзора является введение в особенности современных методов и средств проектирования информационных систем, основанных на использовании 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 [5] (ISO — International Organization of Standardization — Международная организация по стандартизации, IEC — International Electrotechnical Commission — Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 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, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом:

< 1000 функциональных элементов	один человек
1000-4000 функциональных элементов	одна команда разработчиков
> 4000 функциональных элементов	4000 функциональных элементов на одну команду разработчиков

В качестве итога перечислим основные принципы методологии RAD:

· разработка приложений итерациями;

· необязательность полного завершения работ на каждом из этапов жизненного цикла;

· обязательное вовлечение пользователей в процесс разработки ИС;

· необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

· необходимое использование генераторов кода;

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

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

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

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

2. Структурный подход к проектированию ИС

2.1. Сущность структурного подхода

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

Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие:

· принцип «разделяй и властвуй» — принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

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

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

· принцип абстрагирования — заключается в выделении существенных аспектов системы и отвлечения от несущественных;

· принцип формализации — заключается в необходимости строгого методического подхода к решению проблемы;

· принцип непротиворечивости — заключается в обоснованности и согласованности элементов;

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

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

· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);

· DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);

· ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь» (подраздел 2.4).

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

2.2. Методология функционального моделирования SADT

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [4]. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

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

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

· ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

· связность диаграмм (номера блоков);

· уникальность меток и наименований (отсутствие повторяющихся имен);

· синтаксические правила для графики (блоков и дуг);

· разделение входов и управлений (правило определения роли данных).

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

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

2.2.1. Состав функциональной модели

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рисунок 2.1).

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

Рис. 2.1. Функциональный блок и интерфейсные дуги

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

2.2.2. Иерархия диаграмм

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

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

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

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

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

Рис. 2.2. Структура SADT-модели. Декомпозиция диаграмм

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

Рис. 2.3. Одновременное выполнение

Рис. 2.4. Соответствие должно быть полным и непротиворечивым

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

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

Рис. 2.5. Пример обратной связи

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

Рис. 2.6. Пример механизма

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 2.7 показано типичное дерево диаграмм.

Рис. 2.7. Иерархия диаграмм

2.2.3. Типы связей между функциями

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

Тип связи	Относительная значимость
Случайная
Логическая	1
Временная	2
Процедурная	3
Коммуникационная	4
Последовательная	5
Функциональная	6

Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT.

(0) Тип случайной связности: наименее желательный.

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

Рис. 2.8. Случайная связность

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

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

(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке 2.9.

Рис. 2.9. Процедурная связность

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

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

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

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

C = g(B) = g(f(A))

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

Рис. 2.12. Функциональная связность

Значимость	Тип связности	Для функций	Для данных
Случайная	Случайная	Случайная
1	Логическая	Функции одного и того же множества или типа (например, «редактировать все входы»)	Данные одного и того же множества или типа
2	Временная	Функции одного и того же периода времени (например, «операции инициализации»)	Данные, используемые в каком-либо временном интервале
3	Процедурная	Функции, работающие в одной и той же фазе или итерации (например, «первый проход компилятора»)	Данные, используемые во время одной и той же фазы или итерации
4	Коммуникационнная	Функции, использующие одни и те же данные	Данные, на которые воздействует одна и та же деятельность
5	Последовательная	Функции, выполняющие последовательные преобразования одних и тех же данных	Данные, преобразуемые последовательными функциями
6	Функциональная	Функции, объединяемые для выполнения одной функции	Данные, связанные с одной функцией

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

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

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

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

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

· процессы;

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

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

2.3.1. Внешние сущности

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

Внешняя сущность обозначается квадратом (рисунок 2.13), расположенным как бы «над» диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений:

Рис. 2.13. Внешняя сущность

2.3.2. Системы и подсистемы

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

Подсистема (или система) на контекстной диаграмме изображается следующим образом (рисунок 2.14).

Рис. 2.14. Подсистема

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

2.3.3. Процессы

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

Процесс на диаграмме потоков данных изображается, как показано на рисунке 2.15.

Рис. 2.15. Процесс

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

· «Ввести сведения о клиентах»;

· «Выдать информацию о текущих расходах»;

· «Проверить кредитоспособность клиента».

Использование таких глаголов, как «обработать», «модернизировать» или «отредактировать» означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.

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

2.3.4. Накопители данных

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

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

Рис. 2.16. Накопитель данных

Накопитель данных идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

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

2.3.5. Потоки данных

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

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

Рис. 2.17. Поток данных

2.3.6. Построение иерархии диаграмм потоков данных

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

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

· наличие большого количества внешних сущностей (десять и более);

· распределенная природа системы;

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

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

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

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

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

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

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

· правило нумерации — означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

· наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

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

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

· возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

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

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

2.4. Моделирование данных

2.4.1. Case-метод Баркера

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

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

Нотация ERD была впервые введена П. Ченом (Chen) и получила дальнейшее развитие в работах Баркера [8]. Метод Баркера будет излагаться на примере моделирования деятельности компании по торговле автомобилями. Ниже приведены выдержки из интервью, проведенного с персоналом компании.

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

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

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

Первый шаг моделирования — извлечение информации из интервью и выделение сущностей.

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

Рис. 2.18. Графическое изображение сущности

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

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

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

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

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

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

Рис. 2.19.

Следующим шагом моделирования является идентификация связей.

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

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

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

· продавец может получить вознаграждение за 1 или более контрактов;

· контракт должен быть инициирован ровно одним продавцом.

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

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

Рис. 2.22.

Последним шагом моделирования является идентификация атрибутов.

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

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

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

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

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

С учетом имеющейся информации дополним построенную ранее диаграмму (рисунок 2.25).

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

Подтипы и супертипы: одна сущность является обобщающим понятием для группы подобных сущностей (рисунок 2.26).

Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи из группы взаимно исключающих связей (рисунок 2.27).

Рис. 2.25.

Рекурсивная связь: сущность может быть связана сама с собой (рисунок 2.28).

Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть перенесен из одного экземпляра связи в другой (рисунок 2.29).

Рис. 2.29. Неперемещаемая связь

2.4.2. Методология IDEF1

Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Рис. 2.30. Сущности

Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой «/» и помещаемые над блоком.

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

· каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

· каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

· каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

· каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

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

Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается как показано на рис. 2.31 (мощность по умолчанию — N).

Рис. 2.31. Мощность связи

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

Рис. 2.32. Идентифицирующая связь

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

Рис. 2.33. Неидентифицирующая связь

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

Рис. 2.34. Атрибуты и первичные ключи

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

Рис. 2.35. Примеры внешних ключей

3. Характеристики CASE-средств

3.1. Silverrun+JAM

3.1.1. Silverrun

CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса [22] и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм «сущность-связь»).

Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживаемая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.

Структура и функции

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM — Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. В модуле BPM обеспечена возможность работы с моделями большой сложности: автоматическая перенумерация, работа с деревом процессов (включая визуальное перетаскивание ветвей), отсоединение и присоединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля.

Модуль концептуального моделирования данных (ERX — Entity-Relationship eXpert) обеспечивает построение моделей данных «сущность-связь», не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.

Модуль реляционного моделирования (RDM — Relational Data Modeler) позволяет создавать детализированные модели «сущность-связь», предназначенные для реализации в реляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т.д. Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных. На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представления. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.

Менеджер репозитория рабочей группы (WRM — Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.

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

Взаимодействие с другими средствами

Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL. Это позволяет документировать, перепроектировать или переносить на новые платформы уже находящиеся в эксплуатации базы данных и прикладные системы. При использовании моста Silverrun расширяет свой внутренний репозиторий специфичными для целевой системы атрибутами. После определения значений этих атрибутов генератор приложений переносит их во внутренний каталог среды разработки или использует при генерации кода на языке SQL. Таким образом можно полностью определить ядро базы данных с использованием всех возможностей конкретной СУБД: триггеров, хранимых процедур, ограничений ссылочной целостности. При создании приложения на языке 4GL данные, перенесенные из репозитория Silverrun, используются либо для автоматической генерации интерфейсных объектов, либо для быстрого их создания вручную.

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

· Система отчетов. Можно, определив содержимое отчета по репозиторию, выдать отчет в текстовый файл. Этот файл можно затем загрузить в текстовый редактор или включить в другой отчет;

· Система экспорта/импорта. Для более полного контроля над структурой файлов в системе экспорта/импорта имеется возможность определять не только содержимое экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца текстовых полей. Файлы с указанной структурой можно не только формировать, но и загружать в репозиторий. Это дает возможность обмениваться данными с различными системами: другими CASE-средствами, СУБД, текстовыми редакторами и электронными таблицами;

· Хранение репозитория во внешних файлах через ODBC-драйверы. Для доступа к данным репозитория из наиболее распространенных систем управления базами данных обеспечена возможность хранить всю проектную информацию непосредственно в формате этих СУБД.

Групповая работа

Групповая работа поддерживается в системе Silverrun двумя способами:

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

· Сетевая версия Silverrun позволяет осуществлять одновременную групповую работу с моделями, хранящимися в сетевом репозитории на базе СУБД Oracle, Sybase или Informix. При этом несколько разработчиков могут работать с одной и той же моделью, так как блокировка объектов происходит на уровне отдельных элементов модели.

Среда функционирования

Имеются реализации Silverrun трех платформ — MS Windows, Macintosh и OS/2 Presentation Manager — с возможностью обмена проектными данными между ними.

Для функционирования в среде Windows необходимо иметь компьютер с процессором модели не ниже i486 и оперативную память объемом не менее 8 Мб (рекомендуется 16 Мб). На диске полная инсталляция Silverrun занимает 20 Мб.

3.1.2. JAM

Средство разработки приложений JAM [28] (JYACC’s Application Manager) — продукт фирмы JYACC (США). В настоящее время поставляется версия JAM 7 и готовится к выходу JAM 8.

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

Структура и функции

JAM имеет модульную структуру и состоит из следующих компонент:

· Ядро системы;

· JAM/DBi — специализированные модули интерфейса к СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC и т.д.);

· JAM/RW — модуль генератора отчетов;

· JAM/CASEi — специализированные модули интерфейса к CASE-средствам (JAM/CASE-TeamWork, JAM/CASE-Innovator и т.д.);

· JAM/TPi — специализированные модули интерфейса к менеджерам транзакций (например, JAM/TPi-Server TUXEDO и т.д.);

· Jterm — специализированный эмулятор X-терминала.

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

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

· редактор экранов. В состав редактора экранов входят: среда разработки экранов, визуальный репозиторий объектов, собственная СУБД JAM — JDB, менеджер транзакций, отладчик, редактор стилей;

· редактор меню;

· набор вспомогательных утилит;

· средства изготовления промышленной версии приложения.

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

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

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

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

Утилиты JAM включают три группы:

· конверторы файлов экранов JAM в текстовые. JAM сохраняет экраны в виде двоичных файлов собственного формата. В ряде случаев (например для изготовления программной документации проекта) необходимо текстовое описание экранов;

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

· обслуживание библиотек экранов (традиционные операции с библиотеками).

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

Приложения, разработанные с использованием JAM, не требуют так называемых исполнительных (run-time) систем и могут быть изготовлены в виде исполняемых модулей. Для этого разработчик должен иметь компилятор C и редактор связей. Для изготовления промышленной версии в состав JAM входит файл сборки (makefile), исходные тексты (на языке C) ряда модулей приложения и необходимые библиотеки.

JAM содержит встроенный язык программирования JPL (JAM Procedural Language), с помощью которого в случае необходимости можно написать модули, реализующие специфические действия. Данный язык является интерпретируемым, что упрощает отладку. Существует возможность обмена информацией между средой визуально построенного приложения и такими модулями. Кроме того, в JAM реализована возможность подключения внешних модулей, написанных на каком-либо языке, совместимым по вызовам функций с языком C.

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

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

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

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

· внешние JPL-модули. Могут поставляться в виде текстовых файлов или в прекомпилированном виде, причем прекомпилированные внешние JPL-модули могут быть как в виде отдельных файлов, так и в составе библиотек экранов;

· файлы конфигурации приложения — файлы конфигурации клавиатуры и терминала, файл системных сообщений, файл общей конфигурации.

Взаимодействие с другими средствами

Непосредственное взаимодействие с СУБД реализуют модули JAM/DBi (Data Base interface). Способы реализации взаимодействия в JAM разделяются на два класса: ручные и автоматические. При ручном способе разработчик приложения самостоятельно пишет запросы на SQL, в которых как источниками, так и адресатами приема результатов выполнения запроса могут быть как интерфейсные элементы визуально спроектированного внешнего уровня, так и внутренние, невидимые для конечного пользователя переменные. Автоматический режим, реализуемый менеджером транзакций JAM, осуществим для типовых и наиболее распространенных видов операций с БД, так называемых QBE (Query By Example — запросы по образцу), с учетом достаточно сложных взаимосвязей между таблицами БД и автоматическим управлением атрибутами экранных полей ввода/вывода в зависимости от вида транзакции (чтение, запись и т.д.), в которой участвует сгенерированный запрос.

JAM позволяет строить приложения для работы более чем с 20 СУБД: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-совместимые СУБД и др.

Отличительной чертой JAM является высокий уровень переносимости приложений между различными платформами (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS и др.). Может потребоваться лишь «перерисовать» статические текстовые поля на экранах с русским текстом при переносе между средами DOS-Windows-UNIX. Кроме того, переносимость облегчается тем, что в JAM приложения разрабатываются для виртуальных устройств ввода/вывода, а не для физических. Таким образом при переносе приложения с платформы на платформу, как правило, требуется лишь определить соответствие между физическими устройствами ввода/вывода и их логическими представлениями для приложения.

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

При росте нагрузки на систему и сложности решаемых задач (распределенность и гетерогенность используемых ресурсов, количество одновременно подключенных пользователей, сложность логики приложения) применяется трехзвенная модель архитектуры «клиент-сервер» с использованием менеджеров транзакций. Компоненты JAM/TPi-Client и JAM/TPi-Server позволяют достаточно просто перейти на трехзвенную модель. При этом ключевую роль играет модуль JAM/TPi-Server, так как основная трудность внедрения трехзвенной модели заключается в реализации логики приложения в сервисах менеджеров транзакций.

Интерфейс JAM/CASE подобен интерфейсу к СУБД и позволяет осуществить обмен информацией между репозиторием объектов JAM и репозиторием CASE-средства аналогично тому, как структура БД импортируется в репозиторий JAM непосредственно из БД. Отличие заключается в том, что в случае интерфейса к CASE этот обмен является двунаправленным. Кроме модулей JAM/CASEi, существует также модуль JAM/CASEi Developer’s Kit. С помощью этого модуля можно самостоятельно разработать интерфейс (т.е. специализированный модуль JAM/CASEi) для конкретного CASE-средства, если готового модуля JAM/CASEi для него не существует.

Мост (интерфейс) Silverrun-RDM <-> JAM реализует взаимодействие между CASE-средством Silverrun и JAM (перенос схемы базы данных и экранных форм приложения между CASE-средством Silverrun-RDM и JAM версии 7.0). Данный программный продукт имеет 2 режима работы:

· прямой режим (Silverrun-RDM->JAM) предназначен для создания объектов CASE-словаря и элементов репозитория JAM на основе представления схем в Silverrun-RDM. В этом режиме мост позволяет, исходя из представления моделей данных интерфейса в Silverrun-RDM, производить генерацию экранов и элементов репозитория JAM. Мост преобразует таблицы и отношения реляционных схем RDM в последовательность объектов JAM соответствующих типов. Методика построения моделей данных интерфейса в Silverrun-RDM предполагает применение механизма подсхем для прототипирования экранов приложения. По описанию каждой из подсхем RDM мост генерирует экранную форму JAM;

· обратный режим (JAM->Silverrun-RDM) предназначен для переноса модификаций объектов CASE-словаря в реляционную модель Silverrun-RDM.

Режим реинжиниринга позволяет переносить модификации всех свойств экранов JAM, импортированных ранее из RDM, в схему Silverrun. На этом этапе для контроля целостности базы данных не допускаются изменения схемы в виде добавления или удаления таблиц и полей таблиц.

Групповая работа

Ядро JAM имеет встроенный интерфейс к средствам конфигурационного управления (PVCS на платформе Windows и SCCS на платформе UNIX). Под управлением этих систем передаются библиотеки экранов и/или репозитории. При отсутствии таких систем JAM самостоятельно реализует часть функций поддержки групповой разработки.

Использование PVCS (см. подраздел 3.6) является более предпочтительным по сравнению с SCCS, так как позволяет организовать единый архив модулей проекта для всех платформ. Так как JAM на платформе UNIX не имеет прямого интерфейса к архивам PVCS, то выборка модулей из архива и возврат их в архив производятся с использованием PVCS Version Manager. На платформе MS-Windows JAM имеет встроенный интерфейс к PVCS и действия по выборке/возврату производятся непосредственно из среды JAM.

Среда функционирования

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

3.2. Vantage Team Builder (Westmount I-CASE) + Uniface

3.2.1. Vantage Team Builder (Westmount I-CASE)

Vantage Team Builder [14] представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.

Структура и функции

Vantage Team Builder обеспечивает выполнение следующих функций:

· проектирование диаграмм потоков данных, «сущность-связь», структур данных, структурных схем программ и последовательностей экранных форм;

· проектирование диаграмм архитектуры системы — SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа «клиент-сервер», анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);

· генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

· программирование на языке C со встроенным SQL;

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

· многопользовательский доступ к репозиторию проекта;

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

· экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).

Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от остальных некоторой степенью ориентации на спиральную модель ЖЦ ПО за счет возможностей быстрого прототипирования, предоставляемых Uniface. Для описания проекта ИС используется достаточно большой набор диаграмм, конкретные варианты которого для наиболее распространенных конфигураций приведены ниже в таблице.

Тип диаграммы	Обозначение	Vantage Team Builder for ORACLE	Vantage Team Builder for Informix	Vantage Team Builder for Uniface
Сущность-связь	ERD	+	+	+
Потоков данных	DFD	+	+	+
Структур данных	DSD	+	+	+
Архитектуры системы	SAD	+	+	+
Потоков управления	CSD	+	+	+
Типов данных	DTD	+	+	+
Структуры меню	MSD	+
Последовательности блоков	BSD	+
Последовательности форм	FSD	+	+
Содержимого форм	FCD	+	+
Переходов состояний	STD	+	+	+
Структурных схем	SCD	+	+	+

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

При построении DFD обеспечивается контроль соответствия диаграмм различных уровней декомпозиции. Контроль за правильностью верхнего уровня DFD осуществляется с помощью матрицы списков событий (ELM). Для контроля за декомпозицией составных потоков данных используется несколько вариантов их описания: в виде диаграмм структур данных (DSD) или в нотации БНФ (форма Бэкуса-Наура).

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

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

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

Для подготовки проектной документации могут использоваться издательские системы FrameMaker, Interleaf или Word Perfect. Структура и состав проектной документации могут быть настроены в соответствии с заданными стандартами. Настройка выполняется без изменения проектных решений.

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

Процесс проектирования ИС с использованием Vantage Team Builder реализуется в виде 4-х последовательных фаз (стадий) — анализа, архитектуры, проектирования и реализации, при этом законченные результаты каждой стадии полностью или частично переносятся (импортируются) в следующую фазу. Все диаграммы, кроме ERD, преобразуются в другой тип или изменяют вид в соответствии с особенностями текущей фазы. Так, DFD преобразуются в фазе архитектуры в SAD, DSD — в DTD. После завершения импорта логическая связь с предыдущей фазой разрывается, т.е. в диаграммы могут вноситься все необходимые изменения.

Взаимодействие с другими средствами

Конфигурация Vantage Team Builder for Uniface обеспечивает совместное использование двух систем в рамках единой технологической среды проектирования, при этом схемы БД (SQL-модели) переносятся в репозиторий Uniface, и, наоборот, прикладные модели, сформированные средствами Uniface, могут быть перенесены в репозиторий Vantage Team Builder. Возможные рассогласования между репозиториями двух систем устраняются с помощью специальной утилиты. Разработка экранных форм в среде Uniface выполняется на базе диаграмм последовательностей форм (FSD) после импорта SQL-модели. Технология разработки ИС на базе данной конфигурации показана на рисунке 3.1.

Структура репозитория (хранящегося непосредственно в целевой СУБД) и интерфейсы Vantage Team Builder являются открытыми, что в принципе позволяет интеграцию с любыми другими средствами.

Среда функционирования

Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS.

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

Рис. 3.1. Взаимодействие Vantage Team Builder и Uniface

3.2.2. Uniface

Uniface 6.1 [15] — продукт фирмы Compuware (США) — представляет собой среду разработки крупномасштабных приложений в архитектуре «клиент-сервер» и имеет следующую компонентную архитектуру:

· Application Objects Repository (репозиторий объектов приложений) содержит метаданные, автоматически используемые всеми остальными компонентами на протяжении жизненного цикла ИС (прикладные модели, описания данных, бизнес-правил, экранных форм, глобальных объектов и шаблонов). Репозиторий может храниться в любой из баз данных, поддерживаемых Uniface;

· Application Model Manager поддерживает прикладные модели (E-R модели), каждая из которых представляет собой подмножество общей схемы БД с точки зрения данного приложения, и включает соответствующий графический редактор;

· Rapid Application Builder — средство быстрого создания экранных форм и отчетов на базе объектов прикладной модели. Оно включает графический редактор форм, средства прототипирования, отладки, тестирования и документирования. Реализован интерфейс с разнообразными типами оконных элементов управления (Open Widget Interface) для существующих графических интерфейсов — MS Windows (включая VBX), Motif, OS/2. Универсальный интерфейс представления (Universal Presentation Interface) позволяет использовать одну и ту же версию приложения в среде различных графических интерфейсов без изменения программного кода;

· Developer Services (службы разработчика) — используются для поддержки крупных проектов и реализуют контроль версий (Uniface Version Control System), права доступа (разграничение полномочий), глобальные модификации и т.д. Это обеспечивает разработчиков средствами параллельного проектирования, входного и выходного контроля, поиска, просмотра, поддержки и выдачи отчетов по данным системы контроля версий;

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

· Personal Series (персональные средства) — используются для создания сложных запросов и отчетов в графической форме (Personal Query и Personal Access — PQ/PA), а также для переноса данных в такие системы, как WinWord и Excel;

· Distributed Computing Manager — средство интеграции с менеджерами транзакций Tuxedo, Encina, CICS, OSF DCE.

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

В состав компонент Uniface 7 входят:

· Uniface Application Server — сервер приложений для распределенных систем;

· WebEnabler — серверное ПО для эксплуатации приложений в Internet и Intrаnet;

· Name Server — серверное ПО, обеспечивающее использование распределенных прикладных ресурсов;

· PolyServer — средство доступа к данным и интеграции различных систем.

В список поддерживаемых СУБД входят DB2, VSAM и IMS; PolyServer обеспечивает также взаимодействие с ОС MVS.

Среда функционирования Uniface — все основные UNIX — платформы и MS Windows.

3.3. Designer/2000 + Developer/2000

CASE-средство Designer/2000 2.0 фирмы ORACLE [23] является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.

Структура и функции

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE*Method) — структурная методология проектирования систем, полностью охватывающая все этапы жизненного цикла ИС [8,9]. В соответствии с этой методологией на этапе планирования определяются цели создания системы, приоритеты и ограничения, разрабатывается системная архитектура и план разработки ИС. В процессе анализа строятся модель информационных потребностей (диаграмма «сущность-связь»), диаграмма функциональной иерархии (на основе функциональной декомпозиции ИС), матрица перекрестных ссылок и диаграмма потоков данных.

На этапе проектирования разрабатывается подробная архитектура ИС, проектируется схема реляционной БД и программные модули, устанавливаются перекрестные ссылки между компонентами ИС для анализа их взаимного влияния и контроля за изменениями.

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

Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:

· Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);

· Repository Object Navigator — средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;

· Process Modeller — средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR — Business Process Reengineering) и глобальной системы управления качеством (TQM — Total Quality Management);

· Systems Modeller — набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм «сущность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);

· Systems Designer — набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);

· Server Generator — генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;

· Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;

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

Репозиторий Designer/2000 представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория — база данных ORACLE.

Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.

Взаимодействие с другими средствами

Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

Среда функционирования

Среда функционирования Designer/2000 и Developer/2000 — Windows 3.x, Windows 95, Windows NT.

3.4. Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)

ERwin — средство концептуального моделирования БД [24], использующее методологию IDEF1X (см. подраздел 2.5). ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.

Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.

Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рамках рабочей группы.

BPwin — средство функционального моделирования, реализующее методологию IDEF0 (см. подраздел 2.2).

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

Конфигурация	Стоимость, $
ERwin/ERX	3,295
Bpwin	2,495
ERwin/ERX for PowerBuilder, Visual Basic, Progress	3,495
ERwin/ERX for Delphi	4,295
ERwin/Desktop for PowerBuilder, Visual Basic	495
ERwin/ERX for SQLWindows / Designer/2000 / Solaris	3,495 / 5,795 / 6,995
ModelMart 5 / 10 user	11,995 / 19,995
Erwin/OPEN for ModelMart	3,995

S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных [25]. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.

S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется также прямая генерация шаблонов приложений.

CASE.Аналитик 1.1 [3] является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответствии с методологией, описанной в подразделе 2.3. Его основные функции:

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

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

· получение разнообразных отчетов по проекту;

· генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.

Среда функционирования: процессор — 386 и выше, основная память — 4 Мб, дисковая память — 5 Мб, MS Windows 3.x или Windows 95.

Ориентировочная стоимость:

· однопользовательская версия — 605 $;

· многопользовательская версия (одно рабочее место) — 535 $.

База данных проекта реализована в формате СУБД Paradox и является открытой для доступа.

С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством ERwin. При этом из проекта, выполненного в CASE.Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

3.5. Объектно-ориентированные CASE-средства (Rational Rose)

Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [21]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Структура и функции

В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов [21].

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг — восстановление модели проекта по исходным текстам программ.

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

Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

· диаграммы классов;

· диаграммы состояний;

· диаграммы сценариев;

· диаграммы модулей;

· диаграммы процессов;

· спецификации классов, объектов, атрибутов и операций

· заготовки текстов программ;

· модель разрабатываемой программной системы.

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

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

Взаимодействие с другими средствами и организация групповой работы

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA — для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема.

Для управляемой подмодели предусмотрены операции:

· загрузка подмодели в память;

· выгрузка подмодели из памяти;

· сохранение подмодели на диске в виде отдельного файла;

· установка защиты от модификации;

· замена подмодели в памяти на новую.

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

Среда функционирования

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

Для работы системы необходимо выполнение следующих требований:

· Платформа Windows — процессор 80386SX или выше (рекомендуется 80486), память8Mб (рекомендуется 12Mб), пространство на диске 8Mб + 1-3Mб для одной модели.

· Платформа UNIX — память 32+(16*число пользователей)Mб, пространство на диске 30Mб + 20 при инсталляции + 1-3Mб для одной модели.

Совместимость по версиям обеспечивается на уровне моделей.

3.6. Вспомогательные средства поддержки жизненного цикла ПО

3.6.1. Средства конфигурационного управления

Цель конфигурационного управления (КУ) — обеспечить управляемость и контролируемость процессов разработки и сопровождения ПО. Для этого необходима точная и достоверная информация о состоянии ПО и его компонент в каждый момент времени, а также о всех предполагаемых и выполненных изменениях.

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

Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.

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

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

Доступ к архивам PVCS Version Manager возможен не только через сам Version Manager, но и из более чем 50 инструментальных средств, в том числе MS Visual C и MS Visual Basic, Uniface, PowerBuilder, SQL Windows, JAM, Delphi, Paradox и др.

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

PVCS Version Manager функционирует в среде MS Windows, Windows 95, Windows NT, OS/2, SunOS, Solaris, HP-UX, AIX и SCO UNIX и может исполняться на любом персональном компьютере с процессором 80386 или выше, рабочих станциях Sun, HP и IBM (RS-6000).

Другим средством конфигурационного управления является PVCS Tracker [19] — специализированная надстройка над офисной электронной почтой, предназначенная для обработки сообщений об ошибках в продукте, доставке их исполнителям и контроля за исполнением. Интеграция с PVCS Version Manager дает возможность связывать с сообщениями те или иные компоненты проекта. Отчетные возможности PVCS Tracker включают множество разновидностей графиков и диаграмм, отражающих состояние проекта и процесса его отладки, срезы по различным компонентам проекта, разработчикам и тестировщикам. С их помощью можно наглядно показать текущее состояние работы над проектом и ее временные тенденции.

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

· пользователи (Submitters) — имеют ограниченные права на внесение замечаний и сообщений об ошибках в базу данных PVCS Tracker;

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

· тестировщики (Quality Engineers) — имеют право производить основные операции с требованиями и замечаниями;

· сопровождение (Support Engineers) — имеют право вносить любые замечания, требования и рекомендации в базу данных, но не имеют прав по распределению работ и изменению их приоритетности и сроков исполнения;

· руководители (Managers) — имеют право распределять работы между исполнителями и принимать решения о их надлежащем исполнении. Руководителям разных групп могут заданы различные права доступа к базе данных PVCS Tracker.

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

Требование или замечание поступающее в PVCS Tracker проходит четыре этапа обработки:

· регистрация — внесение замечания в базу данных;

· распределение — назначение ответственного исполнителя и сроков исполнения;

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

· приемка — приемка работ и снятие их с контроля или направление на доработку.

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

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

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

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

· успевает ли группа разработчиков справляться с поступающими замечаниями;

· улучшается ли качество программного продукта и какова динамика этого процесса;

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

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

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

PVCS Tracker поддерживает групповую работу в локальных сетях и взаимодействует с СУБД dBase, ORACLE, SQL Server и SYBASE посредством ODBC.

PVCS Tracker может быть интегрирован с любой системой электронной почты, поддерживающей стандарты VIM, MAPI или SMTP.

PVCS Version Manager и PVCS Tracker окружены вспомогательными компонентами: PVCS Configuration Builder и PVCS Notify.

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

Обычная процедура сборки программного продукта с помощью PVCS Configuration Builder состоит из трех шагов:

· строится файл зависимостей между исходными модулями;

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

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

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

PVCS Notify обеспечивает автоматическую рассылку сообщений об ошибках из базы данных пакета PVCS Tracker по рабочим станциям назначения. При этом используется офисная система электронной почты cc:Mail или Microsoft Mail. PVCS Notify расширяет возможности PVCS Tracker и используется только совместно с ним.

PVCS Notify настраивается из среды PVCS Tracker. Настройка включает в себя определение интервала времени, через который PVCS Notify проверяет содержимое базы данных, определение критериев отбора записей для рассылки уведомлений, определение списков адресов для рассылки. После настройки PVCS Notify начинает работу в автономном режиме, автоматически рассылая уведомления об изменениях в базе данных PVCS Tracker.

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

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

3.6.2. Средства документирования

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

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

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

SoDA содержит набор шаблонов документов, определяемых стандартом на программное обеспечение DOD 2167A. На их основе можно без специального программирования создавать новые формы документов, определяемые пользователями.

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

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

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

Среда функционирования SoDA — ОС типа UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800.

SoDA требует по крайней мере 32 MB оперативной памяти, 100-300 MB для установки и 64 MB рабочего пространства на диске.

3.6.3. Средства тестирования

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

Одно из наиболее развитых средств тестирования QA (новое название — Quality Works) [20] представляет собой интегрированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.

QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.

Основными компонентами QA являются:

· QA Partner — среда для разработки, компиляции и выполнения тестов;

· QA Planner — модуль для разработки планов тестирования и обработки результатов. Для создания и выполнения тестов в процессе работы QA Planner вызывается QA Partner;

· Agent — модуль, поддерживающий работу в сети.

Процесс тестирования состоит из следующих этапов:

· создание плана тестирования;

· связывание плана с тестами;

· пометка и выполнение тестов;

· получение отчетов о тестировании и управление результатами.

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

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

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

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

Комплекс QA занимает на жестком диске не более 21МВ. Поддерживаемые платформы: Windows 3.x, Windows 95, Windows NT, OS/2, Macintosh, VMS, HP-UX, AIX, Solaris.

3.7. Примеры комплексов CASE-средств

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

· CASE-средство Silverrun;

· средство разработки приложений JAM;

· мост Silverrun-RDM <-> JAM;

· комплекс средств тестирования QA;

· менеджер транзакций Tuxedo;

· комплекс средств планирования и управления проектом SE Companion;

· комплекс средств конфигурационного управления PVCS;

· объектно-ориентированное CASE-средство Rational Rose;

· средство документирования SoDA.

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

· Vantage Team Builder for Uniface + Uniface (фирмы «DataX/Florin» и «ЛАНИТ»);

· комплекс средств, поставляемых и используемых фирмой «ФОРС»:

· CASE-средства Designer/2000 (основное), ERwin, Bpwin и Oowin (альтернативные);

· средства разработки приложений Developer/2000, ORACLE Power Objects (основные) и Usoft Developer (альтернативное);

Тема: «Проблема использования кейс­технологии на уроках географии в
разных возрастных группах, на примере пятого и восьмого классов».
Курсовой проект
                 
              Выполнил (­а): 
                                                               Ведерникова Т.Ю. 2
Слюдянка
2016 г
Оглавление
Введение…………………………………………………………………………………………………………………………3
1. Общая характеристика метода…………………………………………………………………………………….6
1. 1. Сущность кейс­технологии…………………………………………………………………………………..6
1. 2. Создание кейса и его классификация…………………………………………………………………….8
1. 3. Технология работы с кейсом на уроке…………………………………………………………………..9
1. 4. Учет возрастных особенностей обучающихся в применении метода……………………..11
2. Использование кейс­метода в учебном процессе…………………………………………………………13
2.1. Как работать с кейсом на уроке…………………………………………………………………………..13
2.2. Способ применения кейс­технологии на уроках географии…………………………………..15
Заключение…………………………………………………………………………………………………………………..16
Список используемой литературы………………………………………………………………………………18
Приложение 1……………………………………………………………………………………………………………….19 3
Введение
Современный   учитель   должен   не   только   в   совершенстве   владеть
предметом, методами, средствами и формами организации учебного процесса,
но  также он должен применять  в своей работе  и современные технологии
обучения.   В   последнее   время   в   Российской   школе   активно   применяются
разнообразные технологии. В своей работе я рассмотрю один метод, который
развивает и логику мышления, креативность и коммуникативность. В основе
этой технологии лежит системно­деятельностный подход. 
Системно­деятельностный   подход,   лежащий   в   основе   ФГОС   второго
поколения,   требует   совершенствования   технологий   обучения   для   создания
возможности самостоятельного успешного усвоения новых знаний, умений и
компетентностей. [7]
Залог успешного учения – активная работа ученика на уроке. Известно,
что   познавательная   активность   обучающихся   тем   выше,   чем   сильнее   их
интерес к изучаемому предмету. Однако здесь нельзя полагаться только на
содержание   изучаемого   материала,   важны   и   методы,   с   помощью   которых
школьники вовлекаются в процесс познания.
Познавательный интерес – это важнейший мотив учения школьников,
залог   успеха.   Он   проявляется   в   активности   и   внимании   обучающихся   на
уроках,   в   их   эмоциональных   реакциях,   в   вопросах   к   учителю,   в   желании
  поучаствовать   во   внеклассных
подготовить   сообщения,
  рефераты,
мероприятиях, конкурсах и т.д. 
Основной задачей формирования активности ученика на уроке является
активизация   мыслительной   деятельности   школьников   в  процессе   обучения.
Отсюда следует, что необходима система средств и приемов возбуждения,
поддержания   и   укрепления   интереса   обучающихся   к   урокам   географии, 4
которые   далеко   не   всегда   расцениваются   школьниками   как   интересные   и
нужные.
Неотъемлемой   частью   современного   урока   является   самостоятельная
практическая  деятельность  обучающихся (самостоятельный   познавательный
творческий поиск школьников, решение ими проблемных ситуаций, обучение
формулированию проблем, своей точки зрения, ее аргументации, выбор путей
решения проблемы). Одним из эффективных методов, позволяющим успешно
решать   эти   задачи   является  кейс­метод,   так   как   он   в   большей   степени
ориентирован на социализацию личности ученика.[4]
Цель   работы:   показать   проблему   использования   кейс­технологии   на
уроках, разных возрастных групп, на примере пятых и восьмых классов.
Для   достижения   поставленных   целей   необходимо   решить   следующие
задачи:
­ выяснить, что такое кейс­технология; 
­ показать различные способы использования технологии; 
­  выяснить  влияние  технологии на  развитие  и  мышление  учеников разного
возраста.
Актуальность:   на   данный   момент   метод   «кейс­технология»   весьма
востребован,   поскольку   есть   необходимость   совершенствовать   урок.   Для
устных предметов, проблема восприятия учениками всегда будет актуальна.
Ведь   нам   необходимо   заинтересовать   ученика,   дать   ему   направление,   для
самостоятельного анализа и изучения темы. 
Кейс­метод дает возможность оптимально сочетать теорию и практику,
развивать   навыки   работы   с   разнообразными   источниками   информации.
Обучающиеся   не   получают   готовых   знаний,   а   учатся   их   добывать
самостоятельно,   принятые   решения   в   жизненной   ситуации   быстрее
запоминаются,   чем   заучивание   правил.   Во­вторых,   процесс   решения
проблемы, изложенной в кейсе – это творческий процесс познания, который 5
подразумевает   коллективный   характер   познавательной   деятельности.
Следовательно, обучающиеся учатся соблюдать правила общения:  работать в
группах,   слушать   собеседников,   аргументировать   свою   точку   зрения,
выстроив   логические   схемы   решения   проблемы,   имеющей   неоднозначное
решение.   На   уроке   обучающиеся   не   будут   скучать,   а   будут   думать,
анализировать,   развивать   навыки   ведения   дискуссии.   И   наконец,   даже
слабоуспевающие обучающиеся смогут участвовать в обсуждении вопросов,
так как нет однозначных ответов, которые надо выучить. Они сами смогут
предложить   ответы.   В   жизни   ученикам   пригодится   умение   логически
мыслить, формулировать вопрос, аргументировать ответ, делать собственные
выводы, отстаивать свое мнение. 6
1. Общая характеристика метода.
1. 1. Сущность кейс-технологии.
Наша система образования не стоит на месте. Находясь в постоянном
движении, она всегда преобразуется. Направлено это на то, чтобы у учеников,
появлялись   более   интересные   методы   работы   в   классе.   Особенно,   это
проявляется на устных предметах, например, на географии.
Одной   из   новых   форм   эффективных   технологий   обучения   является
  Кейс
проблемно­ситуативное   обучение   с   использованием   кейсов.
представляет собой описание конкретной реальной ситуации, подготовленное
по   определенному   формату   и   предназначенное   для   обучения   учащихся
анализу разных видов информации, ее обобщению, навыкам формулирования
проблемы и выработки возможных вариантов ее решения в соответствии с
установленными критериями [6].  Название метода произошло от латинского
термина   –   казус   –   запутанный   или   необычный   случай.   Метод   анализа
конкретных ситуаций возник в начале XX века в Школе бизнеса Гарвардского
университета (США).  
 Кейсовая технология (метод) обучения – это обучение действием. Суть
кейс–метода состоит в том, что усвоение знаний и формирование умений есть
результат активной самостоятельной деятельности учащихся по разрешению
противоречий,   в   результате   чего   и   происходит   творческое   овладение
профессиональными знаниями, навыками, умениями и развитие мыслительных
способностей. 
Главной особенностью метода выступает процесс изучения прецедентов,
другими словами, практических ситуаций, имевших место в прошлом. 7
Термин «кейс­метод», «кейс­технология» в переводе с английского как
понятие «case» означает: 
1 ­ описание конкретной практической ситуации, методический прием
обучения по принципу «от типичных ситуаций, примеров – к правилу, а не
наоборот»,   предполагает   активный   метод   обучения,   основанный   на
рассмотрении   конкретных   (реальных)   ситуаций   из   практики   будущей
деятельности   обучающихся,   т.е.   использование   методики   ситуационного
обучения «case – study»[5]; 
2 – набор специально разработанных учебно­методических материалов на
различных носителях (печатных, аудио­, видео­ и электронные материалы),
выдаваемых учащимся (студентам) для самостоятельной работы[2]. 
Чем   отличается   кейс   от   проблемной   ситуации?   Кейс   не   предлагает
обучающимся   проблему   в   открытом   виде,   а   участникам   образовательного
процесса предстоит вычленить ее из той информации, которая содержится в  
описании кейса. Преимуществом кейсов является возможность  оптимально
сочетать   теорию   и   практику,   что   представляется   достаточно   важным   при
подготовке   специалиста.   Метод   кейсов   способствует   развитию   умения
анализировать   ситуации,   оценивать   альтернативы,   выбирать   оптимальный
вариант и планировать его осуществление.
Кейс должен отвечать следующим условиям:
 наличие реально существующей группы людей, организации, на основе
которой разработана ситуация;
 определенная хронология событий, временные рамки,
 наличие реальной проблемы, конфликта,
 ситуация   должна   быть   представлена   в   «событийном»   стиле,   где
отражены не только события, но и персонажи, их действия, поступки;
 действие, разворачивающееся в кейсе, должно содержать интригу. 8
Тематика   кейс­технологии   может   быть   разнообразна   и   может
применяться при изучении любых тем на любом уровне. Конечно, это требует
определенной подготовки и уже имеющих знаний по лексическим темам, так,
чтобы   ученики   могли   закрепить.   Как   правило,   при   применении   кейс
технологии создаются так называемые «фокус­группы». В каждой группе по 4
– 5 человек.
1. 2. Создание кейса и его классификация.
Кейс   представляет   собой   результат   отражательной   деятельности
преподавателя.   Разработка   кейса   является   сложной   задачей,   требующей
эрудиции,   педагогического   мастерства   и   времени.   Кейс   –   это   подбор
соответствующего реального материала, в котором моделируется проблемная
ситуация и отражается комплекс знаний, умений и навыков, которыми нужно
овладеть обучающимся.
Кейсы классифицируются, на:
 практические   кейсы: метод   ситуативного   анализа или метод   деловой
­
переписки. Данные кейсы должны отражать вводимую ситуацию или случай;
 научно­исследовательские   кейсы   или   метод   инцидента,   которые
­
ориентированы на включение ученика в исследовательскую деятельность.
Метод инцидента.
Особенность этого метода в том, что обучающийся сам находит информацию
для принятия решения.  Учащиеся получают краткое сообщение о случае, Для
принятия   решения   имеющейся   информации   явно   недостаточно,   поэтому
ученик должен собрать и проанализировать информацию, необходимую для
принятия   решения.   Так   как   для   этого   требуется   время,   возможна
самостоятельная   домашняя   работа   школьников.   На   первом   этапе   ребята
получают сообщение и вопросы к нему.
Метод ситуационного анализа. 9
Самый   распространенный   метод,   поскольку   позволяет   глубоко   и   детально
исследовать  сложную   ситуацию.  Ученику  предлагается  текст   с  подробным
описанием   ситуации   и   задача,   требующая   решения.   В   тексте   могут
описываться уже осуществленные действия, принятые решения, для анализа
их целесообразности.
Метод деловой переписки.
Учащиеся получают от учителя пакет документов (кейс), при помощи
которых выявляют проблему и пути её решения. Работа по этой технологии,
как и по многим другим, предполагает два этапа: подготовительный и этап
проведения [12].
Классифицироваться   кейсы   могут   и   в   зависимости   от   доминирующей
функции (Приложение 1).
1. 3. Технология работы с кейсом на уроке.
Представить   кейс   на   уроке   можно   различными   способами,   но,   как
правило,   представляется   в   печатном   виде,   однако   включение   в   текст
фотографий,   диаграмм,   таблиц   делает   его   более   наглядным.   В   последнее
время все популярнее становится мультимедиа презентации. Однако фильм,
видео­ и аудиопрезентации могут создавать некоторые проблемы. С печатной
информацией   легче   работать   и   анализировать   ее,   чем   информацию,
представленную, например, в фильме.
Технология работы с кейсом в учебном процессе сравнительно проста и
включает в себя следующие этапы: 
­ индивидуальная самостоятельная работы обучаемых с материалами кейса
(идентификация   проблемы,
предложение решения или рекомендуемого действия); 
  формулирование   ключевых   альтернатив,
­ работа в малых группах по согласованию видения ключевой проблемы и ее
решений; 10
­ презентация и экспертиза результатов малых групп на общей дискуссии (в
рамках учебной группы) [14].
Кейс – стадии:
1 шаг: Сформулируйте одну конкретную проблему и запишите ее.
2 шаг: Выявите и запишите основные причины ее возникновения (причины
формулируются со слов «не» и «нет»). 
1 и 2 шаг представляют ситуацию «минус». Далее ее надо перевести в
ситуацию «плюс».
3 шаг: Проблема переформулируется в цель.
4 шаг: Причины становятся задачами.
5 шаг: Для каждой задачи определяется комплекс мероприятий – шагов
по   ее   решению,   для   каждого   шага   назначаются   ответственные,   которые
подбирают команду для реализации мероприятий.
6 шаг: Ответственные определяют необходимые материальные ресурсы и
время для выполнения мероприятия
7  шаг: Для  каждого  блока  задач  определяется  конкретный продукт  и
критерии эффективности решения задачи.
Обычно кейсы готовятся в пакете, включающем в себя:
1.
вводный кейс (сведения о наличии проблемы, ситуации, явления;
описание границ рассматриваемого явления); 
2.
информационный   кейс  (объем   знаний   по   какой­либо   теме
(проблеме), изложенный с той или иной степенью детальности); 
3.
стратегический   кейс  (развитие   умения   анализировать   среду   в
условиях неопределенности и решать комплексные проблемы со скрытыми
детерминантами); 
4.
исследовательский   кейс
 (аналогичен   групповым   или
индивидуальным   проектам   —   результаты   анализа   некоторой   ситуации
представляются в форме изложения); 11
5.
тренинговый   кейс  (направлен   на   упрочение   и   более   полное
освоение уже использованных ранее инструментов и навыков ­  логических и
т.п.). 
Разбирая   кейс,   обучающиеся   фактически   получают   на   руки   готовое
решение,   которое   можно   применить   в   аналогичных   обстоятельствах.
  проанализированных   кейсов,
Увеличение   в   «багаже»   обучающихся  
увеличивает   вероятность   использования   готовой   схемы   решений   в
сложившейся ситуации, формирует навыки решения более серьезных проблем
[3].
1. 4. Учет возрастных особенностей обучающихся в
применении метода.
Использование   кейсов   в   процессе   обучения   требует   подготовленности
обучающихся,   наличия   у   них   навыков   самостоятельной   работы,   умения
работать   с   текстом,   коммуникативного   взаимодействия,   навыков   решения
проблемных   вопросов.   Неподготовленность   обучающихся,   неразвитость   их
мотивации может приводить к поверхностному обсуждению кейса. В связи, с
чем   в   5,6   классах,   где   согласно   учебному   плану   на   изучение   географии
отведено по одному часу, доминирующей технологией является проблемное
обучение,   которое   подготавливает   к   решению   кейсов,   а   их   активное
использование приходится на 7­9 классы, что позволяет и объем учебного
времени (по 2 часа в неделю).
В   данный   возрастной   период   развития   основной   сферой   интересов
подростков   становится   общение   со   сверстниками   (на   уроках   подростки
стремятся   общаться,   переписываться).   Становится   значимым   то,   какими
видят их одноклассники (статус в классе).  
Среди   актуальных   потребностей   подростков   можно   выделить
следующие: потребность в самопознании, в самооценке, в самоопределении, в
самовоспитании,   в   психологической   и   эмоциональной   независимости,   в
достижении   определенного   социального   статуса.   Подростки   начинают 12
мыслить быстрее (развивается формально­логическое мышление), с радостью
воспринимают   задания,   в   которых   нужно   поразмышлять,   поспорить,
придумать различные варианты решения. 
Кейс­метод  –   инструмент,   позволяющий   применить   теоретические
знания   к   решению   практических   задач.   Метод   способствует   развитию   у
обучающихся самостоятельного мышления, умения выслушивать и учитывать
альтернативную точку зрения, аргументировано высказать свою. С помощью
этого   метода   ученики   имеют   возможность   проявить   и   усовершенствовать
аналитические и оценочные навыки, научиться работать в команде, находить
наиболее рациональное решение поставленной проблемы. [9]
Навыки, которые развивает метод кейсов: [13]
­ аналитические навыки.  К ним можно отнести: умение отличать данные от
информации, классифицировать, выделять существенную и несущественную
информацию, анализировать, представлять и добывать ее, находить пропуски
информации и уметь восстанавливать их. 
­   практические   навыки.  Пониженный   по   сравнению   с   реальной   ситуацией
уровень   сложности   проблемы,   представленной   в   кейсе   способствует
формированию   на   практике   навыков   использования   теории,   методов   и
принципов.
­ творческие навыки. Одной логикой, как правило, кейс­ситуацию не решить.
Очень   важны   творческие   навыки   в   генерации   альтернативных   решений,
которые нельзя найти логическим путем.
­ коммуникативные навыки.  Среди них можно выделить такие как: умение
вести дискуссию, убеждать окружающих. Использовать наглядный материал и
другие медиа ­ средства, кооперироваться в группы, защищать собственную
точку зрения, убеждать оппонентов, составлять краткий, убедительный отчет. 13
­   социальные   навыки  вырабатываются   в   ходе   обсуждения   кейса:   оценка
поведения   людей,   умение   слушать,   поддерживать   в   дискуссии   или
аргументировать противоположное мнение, контролировать себя и т.д.
­   самоанализ.  Несогласие   в   дискуссии   способствует   осознанию   и   анализу
мнения других и своего собственного. Возникающие моральные и этические
проблемы требуют формирования социальных навыков их решения.
2. Использование кейс­метода в учебном процессе.
2.1. Как работать с кейсом на уроке.
Кейс – метод не используется ежеурочно, поэтому дает возможности
сочетания в преподавании других технологий и методов.
Фаза 
работы
До 
занятия
Распределения функций между учащимися и преподавателем.
Действия преподавателя
Действия учащегося
1.Подбирает кейс
2.Определяет основные и
1.Получает кейс и список рекомендованной 
литературы
вспомогательные материалы
для подготовки учащихся
2.Индивидуально готовится
к занятию
3.Разрабатывает сценарий
занятия
1.Организует 
предварительное обсуждение 
Во время 
занятия
1.Задает вопросы, углубляющие понимание 
кейса и проблемы
кейса
2.Разрабатывает варианты 14
2.Делит класс на группы
решений, принимает во внимание мнения 
3.Руководит обсуждением
кейса в группах, 
других
3.Принимает или участвует в
После 
занятия
обеспечивает учащихся 
дополнительными 
сведениями
1.Оценивает работу 
учащихся
2.Оценивает принятые 
решения и поставленные 
вопросы
принятии решений
Составляет письменный отчет о занятии по 
заданной форме
Действия учителя во время обсуждения.
В процессе обсуждения кейса учитель обычно старается воздержаться от
ответов на вопросы. Вместо этого он задает вопросы, дает слово ученикам,
чтобы они сами отвечали на них.
Ключевые вопросы преподавателя при анализе ситуации: «Что вы сделали?»,
«Какие   аспекты   действия   вы   считаете   правильными?»,   «Что   можно   было
сделать лучше?», «Как вы можете решить эту проблему?», «Что мы могли бы
сделать?», «В чем состоит проблема?», «Каковы возможные пути подхода к
проблеме?», «Что может произойти и к чему может привести, если…?
В процессе обсуждения завязывается дискуссия, и в споре рождается истина.
Технология   кейс­стади   делает   основной   акцент   на   самостоятельное
мышление, способность доносить свои мысли до аудитории и конструктивно
отвечать на критику своих оппонентов.
Каждая  группа  должна  представить  свой   вариант  решения  проблемы
всей   аудитории   кратко   и   ясно.   Итоговая   групповая   презентация   обычно 15
занимает   не   более   3   минут,   чтобы   хватило   времени   на   проведение
межгрупповой   дискуссии,   которая   является   естественным   завершением
работы   с   конкретной   ситуацией   и   содержит   в   себе   высокий   развивающий
потенциал.   Важно   рассчитать   время   урока   так,   чтобы   его   хватило   на
межгрупповую дискуссию, иначе подводя итоги урока, учитель навязывает
свою точку зрения на решение проблемы.
На своих уроках, кейс­технологию мы применяем при изучении новых
тем, на повторительно­обобщающих уроках.
2.2. Способ применения кейс­технологии на уроках географии.
Выделяются   несколько   способов  работы   с  кейсом,  в  данной  работе   я
рассмотрю   один,   на   основе   которого,   построю   два   уроках   для   разных
возрастных групп средней школы.
Этапы работы с кейсом
1. Чтение текста 
2. Пересказ текста.
3. Поиск (выделение) 
проблемы. О какой 
проблеме идет речь в 
тексте?
4. Обсуждение. Каковы 
проявления проблемы? – 
составление схемы, 
кластера («смысловой 
грозди»).
5. Выделение критериев 
(признаков идеального 
состояния системы – то, при
Методический комментарий для лучшего
понимания содержания.
Лучше читать 2 раза: про себя и вслух по 
цепочке.
Пересказ осуществляется по цепочке, по ходу 
можно уточнять детали.
Проблем может быть несколько. В этом случае
важно установить связь между ними, их 
соподчинение.
Составление схемы, таблицы, кластера 
помогает затем найти пути решения проблемы.
Это необходимо, чтобы определить к чему 
должны привести пути решения. 16
Запись путей желательна, чтобы не упустить 
важное.
Здесь формируются творческие навыки 
обучающихся.
котором проблемы нет).
6. Определение путей 
решения  проблемы 
(«Мозговой штурм»).
7. Подготовка презентации 
решения группы (возможные
формы):
­ сочинение­миниатюра;
­ опорный контекст;
­ схема;
­ таблица;
­ мультимедийная 
презентация.
8. Презентация итогов 
работы.
 
Для   того   чтобы   результаты   обсуждения   быстро   фиксировались,
целесообразно   в   группы   раздать   рабочие   листы   для   создания   опорных
конспектов.
Заключение.
Применение  кейс   –   метода  позволяет  сформировать   высокую
мотивацию к учебе; реализовать основную ведущую потребность подростков –
общение со сверстниками; развить такие личностные качества, значимые для
будущей профессиональной деятельности, как способность к сотрудничеству,
чувство лидерства; сформировать основы деловой этики.
При   использовании   метода   кейсов   изменилась   роль   учителя   и
обучающихся:   учитель   из   транслятора   знаний   становится   организатором
деятельности   обучающихся,   а   школьники   в   свою   очередь   из   пассивных
слушателей   становятся   активными.   Обучающиеся   должны   разрешить
поставленную   перед   ними   проблему   и   получить   реакцию   окружающих
(учителя   и   других   школьников)   на   свои   действия.   При   этом   они   должны 17
понимать,   что   возможны   различные   решения   проблемы.   А   преподаватель
помогает обучающимся рассуждать, спорить, а не навязывать им своё мнение.
Обучающиеся должны с самого начала понимать, что риск принятия решения
лежит   на   них,   преподаватель   только   поясняет   последствия   принятия
необдуманных   решений.   Роль   учителя   состоит   в   направлении   беседы   или
дискуссии с помощью проблемных вопросов, в контроле времени работы, в
побуждении   обучающихся   отказаться   от   поверхностного   мышления,
вовлечения всех членов группы в процесс анализа кейса. 
Анализируя опыт работы по методу кейсов, напрашивается вывод, что о
преимуществах и затруднениях в использовании данного метода.
Преимущества кейс­метода: 
­ повышение интереса к процессу обучения, урокам, предмету;
­   способствует   повышению   познавательной   активности   обучающихся   в
учебном процессе;
­ развитие и совершенствование творческих способностей обучающихся;
­ активизирует мышление обучающихся;
­ формирует умения работы с большим объёмом информации;
­ формирует коммуникативные навыки;
­ способствует развитию умения общения в группах;
­ способствует развитию здоровой дискуссии;
­ создаёт психологически комфортную среду на уроках;
­ удобно совмещается с другими технологиями;
­   даёт   возможность   педагогу   применять   различные   приёмы   и   методы
обучения.
Таким   образом,   наличие   проблемной   ситуации,   умение   найти
необходимую информацию, коллективно выработанное решение, возможность
нескольких   вариантов   решения   проблемы,   высокая   степень   активности,   а
также управляемый эмоциональный фон отличают кейс – метод от других и 18
способствуют   формированию   познавательного   интереса   обучающихся,
расширению   их   кругозора,   развитию   критического   мышления,   а   также
активизации всего педагогического процесса.
При работе с кейсами есть и сложности:
­ подготовка кейса требует много времени и обилия информации;
­ сложность в подборе информации;
­ не все обучающиеся способны работать с большим объёмом информации,
так как техника чтения не у всех школьников одинаковая;
­   невозможность   частого   использования   метода   в   рамках   классно­урочной
системы.
В заключении надо отметить, что ни один метод обучения не является
универсальным. Обучение с помощью метода кейсов имеет многочисленные
преимущества и содержит недостатки. Поэтому его применение в учебном
процессе должно быть весьма избирательным с точки зрения места и времени.
Только   оптимальное   сочетание   различных   методов   может   принести
максимальный обучающий эффект.
И   чем   более   успешными   и   развитыми   будут   ученики,   тем   большее
удовлетворение от своей работы получает учитель.
Список используемой литературы
1. Мухина С.А., Соловьева А.А. Современные инновационные технологии
обучения.­М: ГЭОТАР­Медиа, 2008.
2. Смолянинова, О.Г. Инновационные технологии обучения студентов на
основе метода CaseStudy // Инновации в российском образовании: сб.­
М.: ВПО, 2000.
3. Гладких   И.В.   Методические   рекомендации   по   разработке   учебных
  Вестник   Санкт­Петербургского   университета.
кейсов.
Менеджмент.­2005. ­ Выпуск 2. с. 169­194.
  Серия: 19
4. Михайлова Е. И. Кейс и кейс­метод: общие понятия / Е.И.Михайлова /
Маркетинг.1999.­ №1.
5. Ситуационный   анализ,   или   анатомия   Кейс­метода   /   под   ред   .Ю.П.
Сурмина – Киев: Центр инноваций и развития, 2002.
6. Кейс­метод
 
в
  школе
 
«ЕСТЕСТВЕННЫЕ   НАУКИ»
http://www.enauki.ru/case
7. Электронный   ресурс   Министерства   образования   и   науки.   Сайт
http://standart.edu.ru/.
Тема урока: «Экологическая ситуация в России».
Приложение 1
Цель   урока:   сформировать   представление   об   экологической   ситуации   в
стране.
Задачи урока: 
Предметные:  определять   причины   и   следствия   геоэкологических
закономерности
 объяснять   основные  
проблем;
взаимодействия общества и природы.
географические 20
Метапредметные:  продолжить   формирование   умений   работать   с
различными источниками информации; развивать навыки работы в группе, в
парах. 
Развивающие: воспитывать бережное отношение к окружающей среде.
Оборудование: УМК, презентация, атласы, схемы.
Мотивационный этап (5 мин.)
Ход урока.
Ученики заходят в класс, и видят на столе учителя карточки разного цвета.
Учитель: «Каждый ученик должен взять карточку любого цвета». Ученики
разбирают карточки и садятся на место. 
Учитель:   «Сегодня   мы   с   вами   постараемся   решить   одну   из   важнейших
проблем.   А   что   эта   за   проблема,   расскажите   вы,   но   давайте   сначала
посмотрим   на   доску»   (на   доске   идет   показ   фильма   на   1мин   20   сек.   об
окружающей среде).
После просмотра фильма ученики предполагают, о чем сегодня пойдет речь, и
какая проблема актуальна.
Ученики: «Возможно, речь пойдет об экологических проблемах России».
Учитель: «Все верно. Какие, вы можете на сегодняшний урок, поставить цели
и задачи?»
Ученики: «Выяснить причины экологической проблемы России и найти пути
ее решения».
Учитель:   «Вы   правильно   сформулировали   нашу   цель.   А   что   бы   найти
проблему и пути ее решения, мы посмотрим на примере нескольких крупных
районов России экологическую ситуацию в стране».
II. Формирование новых знаний 
Учащиеся делятся на группы, по количеству цветных карточек, всего должно
получится 6 групп, по количеству крупных регионов России. Представитель
от   каждой   группы,   должен   подойти   к   доске   и   сорвать   один   из   лепестков 21
ромашки,   то   есть   выбрать   один   из   районов   для   изучения.   В   это   время,
остальные   учащиеся   пишут   в   тетради   тему   урока,   и   таблицу,   которая
представлена на слайде.
На выполнение работы дается 12 мин.
Оценка экологической ситуации в России
Название крупного
Экологическая ситуация
региона
Восточно­
Европейская
равнина
Северный Кавказ
Урал
Западно­
Сибирская равнина
Восточная Сибирь
Дальний Восток
Учитель напоминает критерии оценки «защиты» работы группы и 
организует учащихся на данный вид деятельности. Главными критериями 
оценки ваших выступлений будут соответствие представленного материала 
реальной действительности, краткость, четкость, логичность и 
убедительность изложения, регламент – на «защиту» работы дается всего 2 
минуты, а также адекватное выставление оценки экологической опасности по 
10­ти балльной шкале (10 – самая сложная экологическая обстановка).
 Итак, 
 я приглашаю членов группы №1 с экологической картой  ПК Восточно­
Европейской равнины;
 я приглашаю членов группы №2 с экологической картой ПК Северного 
Кавказа;
 я приглашаю членов группы №3 с экологической картой ПК Урала;
 я приглашаю членов группы №4 с экологической картой ПК Западной 
Сибири; 22
 я приглашаю членов группы №5 с экологической картой ПК Восточной 
Сибири;
 я приглашаю членов группы №6 с экологической картой ПК Дальнего 
Востока.    
Учитель ставит предварительную экспертную оценку группам за работу, 
подводит промежуточные итоги деятельности учащихся, подготавливает их к 
формулированию вывода урока.
Только что мы выслушали комментарии всех рабочих групп к своим 
творческим материалам по оценке экологической ситуации в  России. 
 Какое общее впечатление у Вас сложилось? 
 Какие ПК получились самыми экологически «чистыми» и «грязными».
 Что изменилось в Ваших взглядах на обозначенную проблему сегодня 
по сравнению с тем, что Вы знали по этому вопросу ранее?
 Решаема ли данная проблема у нас в стране и тогда кто ее может 
решить? 
 Можете ли вы уже сейчас внести свой вклад в решении данной 
проблемы, и каким образом?
Учитель подводит итог беседы (вывод урока):
      Итак, собрав воедино все ваши выводы и выступления, можно сказать, что 
Россия – страна огромная, необъятная, и многие ее экологические проблемы 
имеют глобальный характер, но важно одно – мы, россияне, живем в этой 
стране, ходим по ее полям, лугам и леса, дышим ее воздухом, купаемся в ее 
реках. И в каком бы уголке мы не жили, мы должны понимать, что природа – 
она единая, все ее компоненты находятся в тесной взаимосвязи, и если в 
каком­нибудь отдаленном уголке, в частичке какого­то природного 
комплекса экологическое равновесие нарушается, «заболевает» и вся 
природа, и человек как ее неотъемлемая часть. А потому берегите природу, 
будьте с ней взаимовежливыми, и она вас непременно отблагодарит! Домашнее задание.
23
Учитель объявляет домашнее задание, которое является логическим 
продолжением материала урока, и комментирует его, 
Вспоминая материалы урока, дома вам надо:
 определить перспективы развития «своего» природного комплекса, 
 степень личного воздействия на экологию родной страны,  
 наметить мероприятия  по спасению ПК.
В   завершении   урока,   при   выходе   из   кабинета,     учащимся   предлагается
оставить свой голос за урок (цветовой):
 красный – урок неинтересный, неинформативный, ненужный, скучный;
 желтый – урок средний, можно и лучше;
зеленый – урок интересный, яркий, увлекательный, полезный.
Приложение 2
Тема: «Человек и литосфера», 5 класс
Цель: сформировать представление об использовании полезных ископаемых, 
определить условия жизни человека на равнинах и в горах.
Предметные:   приводить   примеры   различных   условий   жизни   в   горах   и   на
равнинах.
Метапредметные: умение организовать свою деятельность, определять ее цели
и задачи, умение вести самостоятельный поиск, анализ, отбор информации, 24
высказывать суждения, подтверждая их фактами, овладение практическими 
умениями работы с учебником.
Личностные: осознание ценности географических знаний, как важнейшего  
компонента научной картины мира.
Методы обучения: частично поисковый, исследовательский,  проблемный.
Тип урока: урок открытия нового знания
Вид урока: урок усвоения нового материала, практикум. 
 Формы работы: индивидуальная, парная, фронтальная.
Оборудование:  учебник, раздаточный материал для практического задания, 
презентация, коллекция горных пород и минералов.
Мотивационный этап.
Приветствие учащихся, проверка готовности учащихся к уроку.
Вот звенит для нас звонок – начинается урок.
Ровно встали, подтянулись и друг другу улыбнулись.
Добрый день, дорогие ребята! Улыбнитесь друг другу, пожелайте хорошего
настроения!  С каким настроением вы пришли на урок географии? 
Актуализация знаний
Задание:   работая   в   паре,   выберите   из   предложенного   списка   слова   и
сгруппируйте их в два столбика. Запишите в маршрутный лист (Приложение
3).   Список   слов:   овраг,   карьер,   гора,   холм,   литосфера,     яма,   котловина,
горный хребет, человек Лишние слова: человек и литосфера. 
Тема сегодняшнего урока «Человек и литосфера»
Что мы будем изучать на данном уроке?
Напишите цели урока в свой маршрутный лист.
Оцените   себя.   Поставьте   самооценку   (памятка   по   самооценке   ­
Приложение №4) в маршрутный лист.
Назовите крупные формы рельефа, которые вы увидели в данных слайдах? 25
Люди живут как на равнинах, так и в горах. А где лучше жить – на равнинах 
или в горах вы ответите, как только выполните следующее задание: у каждой 
команды есть текст, в который нужно вставить пропущенные слова. 
(Приложение №5)
Физминутка на снятие напряжения  и улучшения мозгового кровообращения
Любопытная Варвара смотрит влево, смотрит ­ вправо,
А потом вперед ­ тут немного отдохнет.
А Варвара смотрит вверх­ выше всех, выше всех!
Возвращается обратно ­расслабление приятно.
Шея не напряжена и рас­слаб­ле­на…
А теперь посмотрим вниз­ мышцы шеи напряглись
Возвращаемся обратно­ расслабление приятно.
Шея не напряжена и рас­слаб­ле­на…
Ребята, при заполнении текста, вы увидели, какая польза от равнин и гор. Но 
какая противоположность есть пользе. Все верно, это разрушение, какой же 
вред горы приносят людям. Работа в группах. Две группы заполняют таблицу 
«Природные явления в горах», две остальные группы заполняют таблицу 
«Влияние человека на литосферу» 
Природные явления в горах
Последствия
Название явления
Землетрясения
Извержение 
вулкана 26
Влияние человека на литосферу
Деятельность
Последствия
человека
Добыча   полезных
ископаемых
Распашка земель
Ученики стараются сформулировать вывод, о воздействии природы на 
человека, и воздействие человека на природу.
Итак, можно сказать, что непосредственную роль в жизни нашей планеты, 
играет человек. Действия природы необратимы, мы не можем их остановить, 
но мы можем повлиять друг на друга ради сохранения природы.
Рефлексия
Учитель консультирует, помогает 
Задание: «Обведите свою ладошку.
­ На мизинце продолжите: Я узнал о…
­ На безымянном продолжите: Я  сделал…
­ На среднем пальце продолжите:   Настроение у меня …
­ На указательном – продолжите: Я помог …
­ На большом пальце – продолжите: Мое самочувствие…
Комментарий
М ­ (мизинец) ­ мыслительный процесс: какие знания, опыт я получил?
Б ­ (безымянный) ­ близость цели: что я сегодня сделал и чего достиг?
С ­ (средний) — состояние духа: какое было сегодня у меня преобладающее
настроение, расположение духа? 
У­ (указательный) — услуга, помощь: чем я сегодня помог другим, чем 
услужил, порадовал или поспособствовал?
Б — (большой) — бодрость, физическая форма: каким было моё
Какую оценку я ставлю себе за работу на уроке  2 3 4 5?
самочувствие? 27
Домашнее задание.
§27, 1­4 устно, 5,6 письменно
Маршрутный
_______________________________________________
лист
 
 
1. Определение темы и цели урока.
Приложение 3
 
(Ф.И.) Формы ___________ (проверка д/з)
28
             Выпуклые                               Вогнутые
___________________                    ___________________
___________________                    ___________________
___________________                   ____________________
___________________                   ____________________
___________________                   ____________________
Цельурока_________________________________________________________
__________________________________________________________________
__________________________________________________________________
____________
Памятка по самооценке
Приложение №4
№ Этапы  работы на уроке
1
2
3
Определение темы и цели урока
Работа по составлению схемы
Участие
 
работе
в
 
 
Самооценка
2б.
справился с заданием
–
 
 
самостоятельно
группы 29
1б.   –   обращался   за   помощью
для выполнения задания
0б. – не справился с заданием,
требуется помощь.
(практическая  работа)
Работа  с  текстом
Общий балл
4
5
Перевод баллов в отметку:
7­8б.  – отметка «5»
5­6 б. – отметка «4»
4б – отметка «3»
Желаю удачи!
Люди преимущественно живут на ___________, так как здесь намного проще
_______   здания, заниматься сельским хозяйством, прокладывать дорожную
Приложение №5 30
_______ , заниматься промышленностью. Однако около 20% населения Земли
живет в  ______ местности различной высоты. Преимущественно в горах люди
занимаются  _______  хозяйством и добычей ______ ископаемых.
Жизнь   в   ______   не   только   неудобна,   но   и   опасна.   В   горах   случаются
природные   явления,   способные   уничтожать   целые   поселения   людей.   Это
______________, вулканы, обвалы и оползни. При обвале от горных склонов
отрываются ________, и происходит их ________ вниз. При оползнях горные
_______ сползают в результате их подмывания. Обвалы и оползни могут быть
следствием   землетрясений,   длительных   проливных   _______,   уничтожения
растительности, постройки зданий и прокладки дорог.
 
    На   _________     живет   основная   часть   населения   Земли,   здесь   много
________,   сел,   заводов,   фабрик.   На   равнинах   на   _________   площадях
посажены поля и сады. На равнинах есть месторождения нефти, ________.  На
равнинах многоводные ________ тоже с большим запасом энергии. Равнины
бескрайние, на них встречается много ______________  пейзажей.
В   горах   чистый   ______   ,   простор,   много   долгожителей.   В   горах   _____
участков   для   посевов,   но   зато   много   пастбищ.   В   горах   много   _______,
медных, полиметаллических руд. В горах быстрые бурные ______ с большим
запасом   энергии.   В   горах   –   снежные________,   узкие   живописные   ущелья,
______солнца.
Приложение №5 31
Люди   преимущественно   живут   на   равнинах,   так   как   здесь   намного   проще
строить   здания,   заниматься   сельским   хозяйством,   прокладывать   дорожную
сеть,   заниматься   промышленностью.   Однако   около   20%   населения   Земли
живет в горной местности различной высоты. Преимущественно в горах люди
занимаются сельским хозяйством и добычей полезных ископаемых.
Жизнь в горах не только неудобна, но и опасна. В горах случаются природные
явления, способные уничтожать целые поселения людей. Это землетрясения,
вулканы,   обвалы   и   оползни.   При   обвале   от   горных   склонов   отрываются
породы,   и   происходит   их   обрушение   вниз.   При   оползнях   горные   породы
сползают   в   результате   их   подмывания.   Обвалы   и   оползни   могут   быть
следствием   землетрясений,   длительных   проливных   дождей,   уничтожения
растительности, постройки зданий и прокладки дорог.
    На равнинах живет основная часть населения Земли, здесь много городов,
сел, заводов, фабрик. На равнинах на больших площадях – поля и сады. На
равнинах   есть   месторождения   нефти,   природного   газа.   На   равнинах
многоводные реки тоже с большим запасом энергии. Равнины бескрайние, на
них встречается много живописных пейзажей.
В горах чистый воздух, простор, много долгожителей. В горах мало участков
для   посевов,   но   зато   много   пастбищ.   В   горах   много   железных,   медных,
полиметаллических руд. В горах быстрые бурные реки с большим запасом
энергии.   В   горах   –   снежные   вершины,   узкие   живописные   ущелья,   много
солнца. 32

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Цель курсовой работы: теоретическое обоснование преимущества и недостатков кейс метода.

Задачи курсовой работы:

— провести исторический обзор использования метода кейсов в России;

— рассмотреть сущность кейс-метода;

— изучить Кейс-метод как одну из методик оценки персонала;

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

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

1. Основы кейс-метода

1.1 Исторический обзор использования метода кейсов в России

Метод кейсов впервые появился ещё в XVII веке, но в современном его виде он был применён в начале ХХ века (1909 – 1910г.) в США в Гарвардской школе бизнеса при преподавании экономических дисциплин. Первым начал использовать метод кейсов профессор Коупленд (Copeland). На своих занятиях он наряду с лекциями применял практикумы, на которых презентовал проблему, а его студенты рассматривали различные пути варианты её решения. А уже в 1921г. Коупленд опубликовал первый сборник по написанию ситуационных упражнений (сборник кейсов)^[1].

В настоящее время сосуществуют две классические школы case-study – Гарвардская (американская) и Манчестерская (европейская)^[2]. В рамках первой школы целью метода является обучение поиску единственно верного решения, вторая – предполагает многовариантность решения проблемы. Американские кейсы больше по объему (20-25 страниц текста, плюс 8-10 страниц иллюстраций), европейские кейсы в 1,5-2 раза короче. Сегодня метод case-study завоевал ведущие позиции в обучении, активно используется в зарубежной практике бизнес – образования и считается одним из самых эффективных способов обучения студентов навыкам решения типичных проблем. Так, Гарвардская школа бизнеса выделяет почти 90% учебного времени на разбор конкретных кейсов, сохраняя приоритетное значение метода case-study в обучении бизнесу. Ситуационное обучение по гарвардской методике – это интенсивный тренинг слушателей с использованием видеоматериалов, компьютерного и программного обеспечения. Среднестатистический студент Гарварда или любой другой бизнес-школы за время своего обучения «прорабатывает» сотни кейсов. Каждый год в Гарварде издаются сотни новых кейсов, методических пособий и дополнений к коллекции кейсов. Ставку на использование ситуационного обучения также делает один из известных университетов Северной Америки – Университет Западного Онтарио (Канада).

Повсеместное распространение метода кейсов в мире началось в 70 – 80-е года ХХ века, тогда же метод получил известность и в СССР. Метод кейсов начал использоваться при обучении управленцев, на экономических специальностях ВУЗов, в первую очередь как метод обучения принятию решений.

Значительный вклад в разработку и внедрение этого метода внесли Ю. Ю. Екатеринославский^[3], Ю. Д. Красовский^[4], В. Я. Платов^[5], Д. А. Поспелов^[6].

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

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

Сейчас использование кейс-метода не ограничивается только обучением, он используется как исследовательская методика. В 2003г. в Томске была начата реализация исследовательской программы «Исследование феноменов и тенденций перехода к Открытому образовательному пространству», в рамках которой кейс-метод был использован как исследовательский метод.

1.2 Сущность кейс-метода

Кейс-метод или метод конкретных ситуаций следует отнести к методам активного проблемного, эвристического обучения. Название метода происходит от английского case– случай, ситуация и от понятия «кейс»- чемоданчик для хранения различных бумаг, журналов, документов и пр^[7].

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

Например, перед учителем информатики стоит задача рассказать про алгоритмы упорядочивания информации (фамилии по алфавиту, числа по возрастанию или убыванию и пр.) и учитель пожелал дать этот материал в режиме кейс-метода. Начать надо, как было отмечено выше, с правильной постановки задачи. Задача должна прозвучать так, чтобы она описывала практическую ситуацию^[8].

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

Для дальнейшего решения учитель должен подготовить необходимые данные – «кейс» для решения поставленной задачи. Что может войти в «кейс» в рассмотренном выше примере? Например, это могут быть статьи с описаниями различных способов-алгоритмов упорядочивания информации, статьи с оценкой эффективности этих способов с точки зрения программистского стиля, быстродействия и т.д., неупорядоченная база видов продукции, список поставщиков этих видов продукции, краткое описание деятельности малого предприятия и пр^[9].

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

Поставив правильно задачу и подготовив «кейс», необходимо организовать деятельность обучающихся по разрешению поставленной проблемы^[10]. Работа в режиме кейс-метода предполагает групповую деятельность. Непосредственная цель метода — совместными усилиями каждая из подгрупп обучающихся анализирует ситуацию — case, и вырабатывает практическое решение. В результате организуется деятельность по оценке предложенных алгоритмов и выбору лучшего в контексте поставленной проблемы решения.

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

Выделим некоторые технологические особенности кейс-метода^[11]:

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

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

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

Идеи кейс-метода (метода ситуационного обучения) достаточно просты^[12]:

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

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

3. Результатом метода являются не знания, но и навыки

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

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

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

Решение рекомендуется проводить в 5 ^[13]: Первый этап – с ситуацией, ее особенностями; этап – выделение проблемы (основных выделение факторов и которые могут воздействовать; Третий – предложение концепций тем для штурма»; Четвертый – анализ последствий того или решения; Пятый – решение кейса – одного или вариантов (последовательности указание на возможное проблем, механизмы их и решения.

1.3 Кейс-метод одна из методик персонала

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

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

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

Рассмотрим разные оценки^[14]:

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

Второй После изучения биографии кандидата, им анкеты от 2–4 и утомительного собеседования с уточняющих вопросов кандидату ряд При этом будет использовать тесты, а кто-то разработки. В любом тестирование, как продолжается от 30 минут до 1 Результаты тестирования, могут дать объем информации о в целом. Но, возникает вопрос: они будут возможно ли на них хотя бы с вероятностью 80 %? вопрос заключается в что конкретно мы с помощью тестов: человека, его или восприятие своей профессиональной модель его Сможем ли мы после результатов тестирования что данный будет встречать только с улыбкой на Да, с помощью возможно измерить структурированность мышления и способности кандидата, но не что он их будет в работе. Из теории Берна мы знаем о что люди а иногда и «должны» в своей жизни роли. У оцениваемой на секретаря девушки быть высокие по шкале А (открытость) по Р. Б. Кеттела, но на рабочем секретарь демонстрирует И друзей у нее много, и человек интересный, есть о с ней поговорить. А на месте она натянутая улыбка на красные от волнения на щеках и шее, руки, когда поднос с чаем И вроде атмосфера в здоровая — никто не не хамит девушке. И беседы» с ней регулярно — не помогает. Но совершенно другая и тема для

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

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

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

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

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

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

Эйчар — это который, как должен тонко принципы корпоративной в компании. И именно как эксперт, участвующий в поддержании, данной культуры, заметить в поведении несоответствия, неадекватность укладу, тем традициям, которые в организации годами^[15].

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

или человек, оценку, точно знать при как он хотел чтобы повел кандидат в заданных Должен ясно наличие и выраженность качеств является Если девушка, к нам на собеседование, описала процедуру гостя (упомянув правила делового то мы можем дать характеристику при таких действий. вы мне отказали?» — иногда недоумевающие Ответ может очень простым: что при с кейсом человек ни не улыбнулся. Такие как гостеприимство, вежливость, хозяйственность, развить в течение месяцев или Эти качества годами, с детства. И гораздо легче и научить девушку необходимой процедуры, заставлять ее улыбаться говорить «спасибо» и

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

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

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

Выводы по 1 главе

Метод case-study или конкретных ситуаций английского case – ситуация) – метод проблемно-ситуационного анализа, на обучении путем конкретных задач – (решение кейсов). метод относится к имитационным активным обучения. Кейс-метод в Гарвардской школе в начале 20-го В 1920 г. после сборника кейсов, Wallace B. Donham осуществлен перевод системы обучения в Гарвардской школе на CASE STUDY на основе реальных

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

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

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

2. Алгоритм бизнес-кейса для или обучения

2.1 ситуация

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

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

— чтобы оценить способности того, будет решать

— научить того, будет решать анализировать ситуацию, проблемы и разрабатывать

— чтобы изменить зрения кого-либо на через проработку и другие цели.

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

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

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

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

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

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

2.2 Обоснование проблемы

предоставить данные в включить в кейс изменений оцениваемых соотношение влияющих Можно использовать статистику компании вымышленную, для чтобы в цифрах сложившуюся ситуацию. К описание показателей увольнений в период 10 лет, можно в виде таблицы. мы видим, что компании обновляется на 80 % 3 года. При 28 % сотрудников покидают проработав несколько – до года, 36% — год и 15% покидают компанию 2 года работы. консалтинговых компаний – утечка знаний и приобретенных в компании, информация о клиентах и И это будет не кейса, а симптом, как сотрудники так не уходят из Только ситуацию в нужно описать чтобы готовых в нем не было. И факт, что цифры в кейсе – но не сама проблема, выявить проверяемый который читает кейс впервые.

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

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

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

2.3 Условия решения

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

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

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

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

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

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

2.4 Критерии принятого решения

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

Риск.

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

усилий.

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

времени.

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

Ограничения ресурсов.

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

Выводы по 2

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

Метод кейсов (конкретных ситуаций) дает возможность участникам тренинга разбирать реальные или воображаемые ситуации.

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

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

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

Преимущества метода кейсов:

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

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

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

Недостатки метода кейсов:

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ:

1. Грузкова С.Ю., Камалеева А.Р. «Кейс-метод: история разработки и использования метода в образовании». Современные исследования социальных проблем (электронный научный журнал), Modern Research of Social Problems, №6(26), 2013. – 185 с. – с.24
2. Дейнека А.В. Управление персоналом: Учебник /. – М.: Издательско-торговая корпорация «Дашков и К», 2013. – 292 с .
3. Екатеринославский Ю.Ю. Управленческие ситуации. Анализ и решения — 2008. — 192 с.
4. Колесник Н П Кейс-стади в интерактивном обучении педагогике /Методические рекомендации – в 2-х частях /41 – СПб НП «Стратегия будущего», 2016 — 198 с.
5. Красовский Ю.Д. Организационное поведение. Учебник — Москва: ЮНИТИ-ДАНА, 2012.- 527 с.
6. Платов, В. Я. Деловые игры:разработка, организация, проведение / В. Я. Платов. – М., 1991. – 192 с.
7. Поспелов Д.А. Ситуационное управление: теория и практика , М.: Наука. -Гл. ред. физ.-мат. лит., 1986, -288с.
8. Долгоруков А.М. Сase stady как способ понимания // Практическое руководство для тьютера системы Открытого образования на основе дистанционных технологий. М.: Центр интенсивных технологий образования, 2012. — С. 21-44
9. Козина, И. Case study: некоторые методические проблемы /И.Козина // Рубеж. – 2012. – № 10-11. – С. 177-189.
10. Михайлова Е.А. кейс и кейс-метод: общее понятия //Маркетинг.2013.№1.-с 109-117.
11. Покушалова Л. В. Метод case-study как современная технология профессионально-ориентированного обучения студентов // Молодой ученый. — 2011. — №5. Т.2. — С. 155-157.
12. Шимутина Е. Кейс-технологии в учебном процессе//Народное образование. – 2014. — № 2. – С. 172 – 179.
13. Долгоруков А.Метод case-study как современная технология профессионально-ориентированного обучения– [Электронный ресурс] – Режим доступа: http://www.vshu.ru/lections.php?tab_id=3&a=info&id=2600
14. Магура И.В. Обучение руководителей// Руководитель 21 века. — Электронный ресурс [текст]: Режим доступа: http://www.maguru.ru/articles/?ID=23

1. Грузкова С.Ю., Камалеева А.Р. «Кейс-метод: история разработки и использования метода в образовании». Современные исследования социальных проблем (электронный научный журнал), Modern Research of Social Problems, №6(26), 2013. – с.24 ↑

2. Управление персоналом: Учебник / А.В. Дейнека. – М.: Издательско-торговая корпорация «Дашков и К», 2013. –с.211 ↑

3. Екатеринославский Ю.Ю. Управленческие ситуации. Анализ и решения — 2008. — 192 с. ↑

4. Красовский Ю.Д. Организационное поведение. Учебник — Москва: ЮНИТИ-ДАНА, 2012.- 527 с. ↑

5. Платов, В. Я. Деловые игры:разработка, организация, проведение / В. Я. Платов. – М., 1991. – 192 с. ↑

6. Поспелов Д.А. Ситуационное управление: теория и практика , М.: Наука. -Гл. ред. физ.-мат. лит., 1986, -288с. ↑

7. Михайлова Е.А. кейс и кейс-метод: общее понятия //Маркетинг.2013.№1.-с 109-117. ↑

8. Колесник Н П Кейс-стади в интерактивном обучении педагогике /Методические рекомендации – в 2-х частях /41 – СПб НП «Стратегия будущего», 2016 — 198 с ↑

9. Долгоруков А.Метод case-study как современная технология профессионально-ориентированного обучения– [Электронный ресурс] – Режим доступа: http://www.vshu.ru/lections.php?tab_id=3&a=info&id=2600 ↑

10. Грузкова С.Ю., Камалеева А.Р. «Кейс-метод: история разработки и использования метода в образовании». Современные исследования социальных проблем (электронный научный журнал), Modern Research of Social Problems, №6(26), 2013. – 185 с ↑

11. Козина, И. Case study: некоторые методические проблемы /И.Козина // Рубеж. – 2012. – № 10-11. – С. 177-189. ↑

12. Покушалова Л. В. Метод case-study как современная технология профессионально-ориентированного обучения студентов // Молодой ученый. — 2011. — №5. Т.2. — С. 155-157. ↑

13. Долгоруков А.М. Сase stady как способ понимания // Практическое руководство для тьютера системы Открытого образования на основе дистанционных технологий. М.: Центр интенсивных технологий образования, 2012. — С. 21-44 ↑

14. Шимутина Е. Кейс-технологии в учебном процессе//Народное образование. – 2014. — № 2. – С. 172 – 179. ↑

15. Магура И.В. Обучение руководителей// Руководитель 21 века. — Электронный ресурс [текст]: Режим доступа: http://www.maguru.ru/articles/?ID=23 ↑