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

Текст из файла (страница 2)

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

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

• Руководство по изучению дисциплины;

• Теоретическая часть (учебное пособие);

• Практикум;

• Глоссарий;

• Список рекомендуемой литературы;

• Система контроля.

Можно выделить следующие этапы разработки такого курса:

1. Создание элементов (страниц) электронного курса (инженер- (техник- ) программист);

2. Сборка элементов в единый ресурс (инженер- (техник- ) программист);

3. Проверка на наличие орфографических и иных видов ошибок (начальник);

4. Исправление несоответствий, ошибок (инженер- (техник- ) программист);

5. Публикация готового ресурса в среде обучения (начальник).

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

1. Анализ и обработка материалов, предоставленных тьюторами;

2. Конвертация данных материалов в формат, поддерживаемый системой тестирования;

3. Подготовка теста к публикации, проверка;

4. Размещение в системе тестирования.

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

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

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

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

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

1.3 Постановка задачи и определение основных требований к разрабатываемой системе

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

1. Уменьшение времени поиска по базе готового контента в 2 раза;

2. Уменьшение времени на формирование отчетов на 15 минут;

3. Оперативный доступ к текущим задачам каждого из сотрудников отдела;

Для достижения этих целей необходимо решить следующие задачи:

• Ведение базы данных (отображения, редактирования и сохранения данных):

- всех видов контента,

- сотрудников отдела,

- работ, осуществляемых сотрудниками,

- отчетов.

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

Требования к разрабатываемой системе:

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

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

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

• ввод данных;

• редактирование данных;

• хранение данных;

• просмотр данных;

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

Требования к надежности

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

Требования к информационной и программной совместимости

Автоматизированная система должна обеспечивать информационную совместимость с известными приложениями операционной системы Windows (MS Word, MS Excel, MS Access). Программная совместимость обеспечивается автоматически в связи с использованием программных средств, совместимость которых обеспечена конструктивно (на этапе их создания) – Delphi, MS Access и т.д. Система реализуется под операционной системой Windows XP-Vista и СУБД InterBase.

Требования к техническому и аппаратному обеспечению

Разрабатываемая система ориентирована на использование персональным компьютером класса IBM PC, начиная с Pentium III, включенного в локальную сеть.

Необходимое аппаратное обеспечение:

– компьютер типа Pentium III или старше,

– минимум 64 Мб оперативной памяти.

Необходимый объем свободного пространства на жестком диске составляет 2 Мб. При работе с приложением в ходе модификации баз данных объем требуемого дискового пространства возрастает в зависимости от объема хранимых данных.

1.4 Анализ существующих разработок

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

Среди подобных систем, имеющих распространение, можно выделить программный модуль «БЭРОН» («Банк электронных ресурсов образовательного назначения»).

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

Ресурс, заносимый в БЭРОН, может быть также позиционирован по виду и назначению.

БЭРОН реализуется в виде трех самостоятельных рабочих мест: пользователя, создателя, администратора. Пользовательское рабочее место обеспечивает возможности поиска требуемых ресурсов по классификатору, по атрибутам. Производит формирование выборок и сортировку данных внутри выборок.

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

Рассмотрим данный продукт с точки зрения решения поставленных задач:

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

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

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

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

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

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

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

Глава 2. Проектирование системы учета работ по созданию электронных образовательных ресурсов

2.1 Выбор методологии

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

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

• ГОСТ 34.601-90 распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла;

• ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного программного обеспечения. Стандарт не содержит описания фаз, стадий этапов;

• Rational Unified Process (RUP) от Rational Software предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан к использованию конкретных средств моделирования (Unified Modeling Language, UML), а так же конкретной технологии проектирования и разработки;

• Microsoft Solution Framework (MSF) представляет общую методологию разработки и внедрения решений в сфере информационных технологий (Information Technologies, IT). Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT-проектов. Последняя версия модели дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения и включает пять фаз: анализ, проектирование, разработка, стабилизация и внедрение, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений;

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

Методологии ГОСТ 34.601-90 и ISO/IEC 12207:1995 не поддерживают объектно-ориентрованный подход, поэтому использоваться не будут.

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

Таблица 2.1. Сравнительный анализ методологий проектирования

В соответствии с проведенным анализом, для проектирования ИС выбрана методология RUP (Rational Unified Process) - одна из технологий, претендующая на роль фактического стандарта.

Рис. 2.1. Жизненный цикл программного обеспечения по RUP

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

1. Бизнес-моделирование (Business modeling);

2. Управление требованиями (Requirements);

3. Анализ и Проектирование (Analysis and Design);

4. Реализация (Implementation);

5. Тестирование (Test);

6. Развертывание (Deployment).

И три вспомогательные:

1. Управление проектом (Project management);

2. Управление изменениями (Change management);

3. Среда (Environment).

Каждый цикл, в свою очередь, разбивается на 4 стадии:

1. начальная стадия (Inception),

2. стадия разработки (Elaboration),

3. стадия конструирования (Construction),

4. стадия ввода в действие – (Transition).

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

Характеристики

Список файлов ВКР