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

Размещено на http://www.allbest.ru/

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

"Национальный исследовательский университет

"Высшая школа экономики"

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

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

Коварин И.С.

Научный руководитель

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

О.Л. Викентьева



Введение

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

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

Существует большое количество программных продуктов, автоматизирующих проведение деловых игр, таких как "MobLab" от MobLab Inc, SimulTrain от Sauter Training & Simulation и Innov8 от IBM. Такие решения являются мощным средством разработки деловых игр в основном в сферах маркетинга и управления проектами. Однако, подобные системы обладают рядом недостатков, в частности, отсутствием поддержки разных предметных или функциональных областей, учета специфики организации бизнес-процессов. Кроме того, имеет место высокая стоимость продуктов.

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

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

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

Сложность моделирования бизнес-процессов (что обосновывает разделение на автоматную и операционную модель).

Большое количество состояний автомата, реализующего деловую игру (ЛСА).

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

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

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

Выполнить анализ существующих алгоритмов для построения АМ и ОМ.

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

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

Выполнить перепроектирование интерфейса

Разработать алгоритм формирования сценария

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

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



1. Анализ предметной области

1.1 Деловые игры в развитии компетенций

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

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

Понятие компетенции является весьма емким и разными авторами трактуется по_разному. Приведем несколько определений. В своей работе, посвященной продвижению Болонского процесса, Д. Гонзалес и Р. Вагенаар описывают компетенции, как индивидуальные характеристики человека, которые в своей случайной совокупности обеспечивают хорошую или отличную производительность труда [1]. Е.В. Харитонова в своей работе на тему различия понятий компетентности и компетенции определяет последнюю как способность установления связи между жизненным опытом и конкретной ситуацией или, иными словами, как умение выработать действие, подходящее для решения проблемы [2]. Данные определения можно назвать достаточно общими, так как в них не содержится явных упоминаний профессиональных качеств человека, которые являются основой его труда.

В свою очередь, И. П. Мединцева рассматривает компетенции в проекции на область образования. По ее мнению, компетенции стоит понимать, как сквозные метапредметные образования, интегрирующие как традиционные знания, так и разного рода обобщенные интеллектуальные, коммуникативные, креативные, методологические, мировоззренческие и иные умения [3].

Компетенция с точки зрения профессиональной квалификации работника рассматривается в работе О.Л. Викентьевой, Л.В. Шестаковой и А.И. Дерябина, посвященной концепции компетентностной деловой игры. Согласно им, компетенция - это способность применять знания, умения, навыки и личностные качества для успешной деятельности в определенной профессиональной сфере [4]. В основе описываемой теории лежат новые образовательные стандарты, центральными понятиями которых и являются компетенции.

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

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

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

1.2 Анализ подходов к проектированию деловых игр

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

Для понимания сути проектирования деловой игры необходимо рассмотреть роль данного процесса в ходе разработки игры. Проанализируем процесс проектирования в различных подходах к разработке деловых игр. Согласно И.А. Ковалевичу и В.Т. Ковалевичу, разработка деловых игр включает четыре основных этапа [6]:

Постановка задач.

Проектирование сценария.

Реализация сценария.

Апробация деловой игры.

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

Е.В. Зарукина выделяет следующие этапы процесса разработки деловой игры [7]:

Выбор темы.

Определение целей.

Моделирование имитируемого объекта.

Разработка сценария.

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

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

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

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

Разработка инструкции.

Описание проблемы, решаемой в ходе игры.

Выделение компонентов игры.

Конструирование и проверка игры.

Оценка игры.

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

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

Концепция СКДИ

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

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

Рисунок 1.1. Архитектура СКДИ.

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

Назначение каждой из подсистем СКДИ изображены в таблице 1.1:

Таблица 1.1. Подсистемы СКДИ

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

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

1.3 Структура подсистемы проектирования

Подсистема проектирования служит для преобразования описания бизнес-процессов в сценарий деловой игры [4]. Сама подсистема имеет сложную многокомпонентную архитектуру. Визуальное представление процесса проектирования деловой игры в рассматриваемой подсистеме изображено на рисунке 1.2

Описание бизнес-процесса предприятия, поступающее на вход подсистемы проектирования, формализуется согласно нотации языка описания унифицированных бизнес-процессов [9]. Данный подход позволяет абстрагироваться от свойственных только определенным предприятиям особенностей бизнес-процесса и составить более обобщенное его представление.

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

Рисунок 1.2. Архитектура подсистемы проектирования.

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

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

L= { Н, А, Р, щ, ^, v, К },

где

Н - оператор начала алгоритма,

К - оператор конца алгоритма,

Р - условный переход,

А - управляющее воздействие,

щ- безусловный переход,

^ - начало перехода,

v - окончание перехода.

ЛСА лежит в основе автоматной модели, которая реализует механизм управления ходом деловой игры. Хранилище ресурсов деловой игры реализует операционная модель. Данные модели являются главными компонентами подсистемы проектирования. Их взаимодействие построено по принципу объект управления - субъект управления соответственно [4].

На данный момент существуют механизмы перехода от описания бизнес-процессов к модели ресурсов деловой игры и ЛСА, выполненные в виде двух отдельных программных средств. Оба решения представляют собой интерактивные графические редакторы, разработанные в соответствии с паттерном проектирования Model-View-ViewModel на основе свободно распространяемого продукта на платформе Windows Presentation Foundation.

Заявленный функционал Редактора бизнес-процессов включает следующее:

построение модели УБП в виде последовательности операций;

автоматическая генерация модели УУБП;

автоматическая генерация ЛСА;

сохранение моделей в XML-файл и их загрузка оттуда.

При этом приложение позволяет реализовывать не все объекты, требуемые нотациями языков описания УБП и УУБП. В частности, нет возможности:

добавлять условия в модель УБП;

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

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

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

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

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

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

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

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

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

Определение цели.

Выбор методики.

Разработка средств интеграции.

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

1.4 Анализ подходов к интеграции приложений

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

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

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

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

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

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

Процесс интеграции информационных систем можно также рассматривать с точки зрения объекта интеграции [11]. Визуальное представление данной классификации изображено на рисунке 1.3:

Рисунок 1.3. Интеграция с точки зрения объекта.

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

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

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

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

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

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

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

модели бизнес-процессов, заложенные в них;

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

Оба прототипа реализованы на основе редактора с открытым кодом WPF Diagram Designer. При этом, редактор ресурсов имеет подключения к базе данных MS SQL Server, предназначенной для хранения всей информация о создаваемых моделях. У приложений совпадает шаблон проектирования, по которому они построены: Модель - Представление - Модель представления (MVVM).

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

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

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

Процесс интеграции будет описан в третьей главе данной работы.

Анализ бизнес-процесса "Проектирование деловой игры" в состоянии "как есть"

Текстовое описание

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

Владельцы бизнес-процесса:

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

Викентьева О.Л.

Дерябин А.И.

Шестакова Л.В.

Управление операциями бизнес-процесса:

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

Механизмы и исполнители:

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

Входные ресурсы:

На вход данного бизнес процесса поступает неформализованное описание бизнес-процесса, имитируемого деловой игрой.

Выходные ресурсы:

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

Логическая схема алгоритма.

Ресурсы деловой игры.

Составляются вручную:

Описания точек принятия решений.

Роли игроков.

Параметры оценки компетенций.

Операции бизнес-процесса:

Анализ предметной области.

Неформализованное описание бизнес-процесса.

Моделирование бизнес-процесса.

Генерация модели учебного бизнес-процесса.

Ручное заполнение точек принятия решений.

Генерация ЛСА.

Создание моделей ресурсов.

Ручное сопоставление ресурсов и операций.

Создание сценария деловой игры.

События бизнес-процесса:

Появление заявки на проектирование деловой игры.

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

Бизнес-процесс описан.

Модель рабочего бизнес-процесса разработана.

Модель учебного бизнес-процесса сгенерирована.

Точки принятие решения заполнены вручную.

ЛСА сгенерирована.

Модели ресурсов созданы.

Операции и ресурсы сопоставлены.

Сценарий деловой игры разработан.

Формальное описание

Модель бизнес-процесса "Проектирование деловой игры" в состоянии "как есть" представлена на рисунке 1.4.

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

заполнение точек принятия решения;

сопоставление ресурсов и операций;

написание сценария деловой игры;

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

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



Рисунок 1.4. Модель бизнес-процесса в состоянии "как есть".

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

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



2. Проектирование программного модуля

2.1 Анализ бизнес-процесса "Проектирование деловой игры" в состоянии "как должно быть"

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

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

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

Владелец бизнес-процесса

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

Управление операциями бизнес-процесса

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

Механизмы и исполнители

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

Входные ресурсы

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

Выходные ресурсы

На выходе процесса будут разработаны следующие модели:

Алгоритм унифицированного БП.

Модели операций бизнес-процесса.

Модель учебного унифицированного бизнес-процесса (карта операций).

Логическая схема алгоритма.

При этом, предполагается, что ЛСА и карта операций будут генерироваться автоматически на основе УБП.

Операции бизнес-процесса

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

Анализ предметной области.

Неформальное описание бизнес-процесса.

Моделирование унифицированного бизнес-процесса.

Создание ресурсов операций бизнес-процессов.

Генерация модели учебного бизнес-процесса.

Генерация ЛСА.

События бизнес-процесса:

Появление заявки на проектирование деловой игры.

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

Бизнес-процесс описан.

Модель унифицированного бизнес-процесса разработана.

Ресурсы операций созданы.

Модель учебного бизнес-процесса разработана.

ЛСА сгенерирована.

Формальное описание

Модель бизнес-процесса "Проектирование деловой игры" в состоянии "как должно быть" представлена на рисунке 2.1:

Рисунок 2.1. Модель бизнес-процесса в состоянии "как должно быть".



2.2 Перепроектирование языка описания учебных унифицированных бизнес-процессов

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

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

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



Таблица 2.1. Язык описания унифицированных учебных бизнес-процессов

Метамодель	Элемент	Описание
Операция	Контрагент	Объект внешней среды.
	Операция	Активность в бизнес-процессе.
	Поток	Используемые и изменяемые ресурсы в операции.
	Трудовой ресурс	Трудовой ресурс выполняет операцию.
	Информационный ресурс	Информационный ресурс может регламентировать операцию, он также может быть изменен или добавлен в процессе ее выполнения.
	Услуга	Услуга может быть произведена при выполнении операции, а также потреблена или продана.
	Товар	Товар может быть получен, произведен или потреблен в процессе выполнения операции.
	Финансовый ресурс	Финансовый ресурс может уменьшаться или увеличиваться с выполнением операции.
	Оборудование	Оборудование, необходимое для выполнения операции.
Точка принятия решения	Вызывающая операция	Операция, за которой наступает момент выбора следующей операции.
	Реакция	Решение или действие игрока, или его оппонента, организует диалог между последними и приводит к результирующей операции или концу бизнес-процесса.
	Результирующая операция	Один из возможных вариантов развития событий в бизнес-процессе.
Карта операций	Начало БП	Начало активности бизнес-процесса.
	Конец БП	Завершение активности бизнес-процесса при достижении цели бизнес-процесса или ошибки.
	Операция	Некоторое действие, необходимое для достижения цели бизнес-процесса
	Точка принятия решения	Момент принятия игроком решения о следующей операции, реализует механизм многовариантности развития событий.
	Ошибка	Возникает при выборе набора ресурсов, приводящем к выполнению операций в неправильном порядке.

Функциональные требования

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

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

при открытии формы должны отобразиться рабочая область для создания модели УБП, область для выбора элементов для модели и область атрибутов;

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

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

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

по завершении создания модели УБП должна обеспечиваться автоматическая генерация модели УУБП;

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

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

на основе модели УУБП должна автоматически формироваться ЛСА;

по завершении генерации ЛСА должно отобразиться окно ее редактирования;

должна быть возможность внесения изменений в выражение ЛСА;

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

Описание прецедентов

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

Отобразить рабочий экран УБП.

Отобразить список атрибутов модели УБП.

Отобразить панель элементов УБП.

Добавить элемент модели УБП.

Удалить элемент модели УБП.

Сгенерировать модель УУБП.

Отобразить рабочий экран УУБП.

Отобразить панель элементов УУБП.

Отобразить список атрибутов модели УУБП.

Добавить элемент модели УУБП.

Удалить элемент модели УУБП.

Сгенерировать ЛСА.

Отобразить панель редактирования операций.

Отобразить список атрибутов операций.

Отобразить список атрибутов ресурса.

Добавить ресурс.

Удалить ресурс.

Отобразить экран редактирования ЛСА.

Проверить правильность ЛСА.

Сохранить модель в базу данных.

Загрузить модель из базы данных.

Список прецедентов представлен на диаграмме вариантов использования UML (рисунок 2.2). Для упрощения визуального представления прецеденты сохранения моделей и загрузки из базы данных описаны в виде комментариев:

Рисунок 2.2. Диаграмма вариантов использования UML.

В таблице 2.2 представлено сопоставление прецедентов и функциональных требований:

Таблица 2.2. Прецеденты и функциональные требования

Требование	Субъект	Прецедент
При открытии формы должны отобразиться рабочая область для создания модели УБП, область для выбора элементов для модели и область атрибутов.	Проектировщик	Отобразить рабочий экран УБП
Для создания и редактирования модели должна быть возможность перетащить элементы из набора в рабочую область, редактировать их атрибуты, изменять размер, а также протягивать однонаправленные связи между ними.	Проектировщик	Редактировать модель УБП
Для создания моделей ресурсов, при двойном нажатии на элемент операции должен открываться экран редактирования ресурсов, содержащий список возможных ресурсов, список ранее добавленных ресурсов и рабочую графическую область	Проектировщик	Отобразить экран редактирования ресурсов
Необходимо иметь возможность добавить ресурс, редактировать его атрибуты, и, в случае необходимости, удалять ресурс из модели	Проектировщик	Редактировать модель ресурсов
По завершении создания модели УБП должна обеспечиваться автоматическая генерация модели УУБП	Проектировщик	Сгенерировать модель УУБП
После генерации модели УУБП должны отобразиться рабочая область для ее редактирования, область для выбора элементов модели и область атрибутов	Проектировщик	Отобразить рабочий экран УУБП
Должна быть возможность добавлять и удалять элементы, изменять их атрибуты, местоположение и внешний вид	Проектировщик	Редактировать модель УУБП
После формирования модели УУБП должна автоматически формироваться ЛСА	Проектировщик	Сгенерировать ЛСА
По завершении генерации ЛСА должно отобразиться окно ее редактирования	Проектировщик	Отобразить экран редактирования ЛСА
Должна быть возможность внесения изменений в выражение ЛСА	Проектировщик	Редактировать выражение ЛСА
Помимо функций, связанных с последовательным моделированием сценария деловой игры, должна быть возможность сохранения моделей в базу данных и загрузки ранее сохраненных моделей из нее	Проектировщик	Сохранить модель в базу данных
	Проектировщик	Загрузить модель из базы данных

Более подробное описание каждого прецедента находится в таблице 2.3:

Таблица 2.3. Описание прецедентов

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

Подобные документы

• Моделирование бизнес-процессов "Студия компетентностных деловых игр"

  Разработка языка для моделирования реальных бизнес-процессов в рамках "Студии компетентностных деловых игр". Использование DSM-платформа MetaEdit+. Составление требований к разрабатываемому языку программирования. Правила разработки метамодели языка.
  
  курсовая работа [1,6 M], добавлен 05.10.2014
  

• Построение моделей учебных бизнес-процессов для проведения деловых игр

  Описание разработки универсального языка для моделирования учебных бизнес-процессов в рамках проекта по разработке "Студии компетентностных деловых игр". Создание графа метамодели и визуальных представлений объектов. Модель точки принятия решения.
  
  отчет по практике [3,7 M], добавлен 08.10.2014
  

• Разработка программного модуля для компьютерной игры

  Основные стадии разработки, принципы тестирования и отладка программного модуля "VFS". Особенности проектирования на языке UML. Методы "грубой силы" и их применение при отладке программы. Вредные факторы, присутствующие на рабочем месте программиста.
  
  дипломная работа [827,0 K], добавлен 07.03.2012
  

• Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО "КИЭП "Энергомера"

  Проектирование базы данных, информационной подсистемы PLC-Tester, модуля тестирования и web-приложения. Разработка логической структуры программного продукта и общие требования к техническому обеспечению. Запуск программы и описание тестовых прогонов.
  
  дипломная работа [3,2 M], добавлен 30.06.2011
  

• Разработка программного модуля

  Структурная диаграмма программного модуля. Разработка схемы программного модуля и пользовательского интерфейса. Реализация программного модуля: код программы; описание использованных операторов и функций. Вид пользовательской формы с заполненной матрицей.
  
  курсовая работа [215,3 K], добавлен 01.09.2010
  

• Разработка объектно-ориентированной модели информационной подсистемы для приемной комиссии университета

  Этапы разработки объектно-ориентированной модели информационной подсистемы приемной комиссии для учета абитуриентов. Создание диаграмм для моделирования процесса обмена сообщениями между объектами. Порядок генерации программного кода на языке С++.
  
  курсовая работа [429,3 K], добавлен 29.06.2011
  

• Разработка программного продукта "цеховое планирование"

  Анализ современных информационных технологий цехового планирования. Разработка математической модели объекта проектирования. Формализация модели бизнес-процесса АРМа цехового плановика. Детальная разработка модулей программного продукта планирования.
  
  дипломная работа [4,9 M], добавлен 29.06.2012
  

• Построение моделей учебных бизнес-процессов для проведения деловых игр

  Разработка языка для моделирования учебных бизнес-процессов в рамках проекта "Студия компетентностных деловых игр", требования к ним. Практическая реализация разработанного языка на DSM-платформе MetaEdit+. Создание визуальных представлений объектов.
  
  курсовая работа [2,1 M], добавлен 06.10.2014
  

• Основы мехатроники

  Теоретические основы проектирования мехатронных систем и модели их жизненного цикла. Разработка алгоритма процесса проектирования системы. Основные идеи CALS-технологии. Особые условия производства и эксплуатации. Структура процесса проектирования.
  
  курсовая работа [3,9 M], добавлен 12.07.2009
  

• Проектирование программного средства "Действия над матрицами"

  Разработка алгоритма поставленной задачи и реализация средствами автоматизированного проектирования. Составление программного продукта на основе готовой спецификации на уровне модуля, проведение его тестирования, использование инструментальных средств.
  
  контрольная работа [257,5 K], добавлен 01.05.2015
  

• Разработка объектно-ориентированной модели информационной подсистемы стоматологическая поликлиника

  Описания порядка генерации программного кода на языке С++ для информационной подсистемы. Исследование добавления деталей к описаниям операций и определения атрибутов классов. Характеристика сбора, хранения, обработки информации о ходе лечебного процесса.
  
  курсовая работа [626,9 K], добавлен 29.06.2011
  

• Разработка подсистемы учета медикаментов в распределенной системе

  Описание особенностей подсистемы обеспечения медикаментами. Разработка структуры базы данных, схемы алгоритма и программного модуля, структуры реестра. Обоснование выбора языка программирования. Оценка надежности и классификация ошибок программы.
  
  дипломная работа [1,3 M], добавлен 25.12.2014
  

• Проект программного модуля для нахождения корня уравнения

  Методика разработки программного модуля для нахождения методом хорд корня уравнения x3-x-0,3=0 с точностью до 0,001 на языке программирования Visual Basic for Application. Схема программного модуля и описание процедуры обработки кнопки "Найти корни".
  
  курсовая работа [394,0 K], добавлен 08.09.2010
  

• Разработка корпоративной информационной системы на примере ООО "Сибирский центр программного обеспечения"

  Анализ и разработка информационной системы, структура сети предприятия. Описание процесса разработки конфигураций и выявление потребностей в автоматизации функций. Средства разработки проектирования и архитектура базы данных. Разработка модели угроз.
  
  дипломная работа [1,4 M], добавлен 13.07.2011
  

• Разработка программного модуля на основе понятийно-тезисной модели

  Сравнительный анализ технологий тестирования. Разработка программного модуля "Интеллектуальная обучающая система для широкого перечня курсов". Обоснование необходимости и важности этапа отладки в процессе разработки данного программного обеспечения.
  
  дипломная работа [101,2 K], добавлен 17.06.2011
  

• Разработка приложения "Передачи данных по сети"

  Проектирование программного модуля: сбор исходных материалов; описание входных и выходных данных; выбор программного обеспечения. Описание типов данных и реализация интерфейса программы. Тестирование программного модуля и разработка справочной системы.
  
  курсовая работа [81,7 K], добавлен 18.08.2014
  

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

  Порядок работы менеджера турфирмы. Анализ рынка программных приложений для ведения туристического бизнеса. Выбор средств проектирования и разработки системы управления баз данных. Разработка, реализация и анализ работы программного модуля, его запуск.
  
  дипломная работа [3,4 M], добавлен 19.07.2015
  

• Разработка программного приложения "DES"

  Спецификация требований к разрабатываемому приложению. Разработка структурной схемы интерфейса. Описание алгоритма шифрования DES. Разработка программного кода приложения "DES". Проведение исследования основных шагов для генерации ключей и шифрования.
  
  курсовая работа [398,4 K], добавлен 13.12.2022
  

• Модели жизненного цикла программного обеспечения

  Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.
  
  презентация [874,4 K], добавлен 19.09.2016
  

• Разработка объектно-ориентированной модели информационной подсистемы "Деканат: экзаменационная сессия"

  Разработка объектно-ориентированной модели информационной подсистемы учета студентов университета во время экзаменационной сессии с помощью программы Rational Rose 2000, с использованием языка UML. Порядок генерации программного кода на языке С++.
  
  курсовая работа [689,9 K], добавлен 21.06.2011
  

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