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

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

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

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

ü ГОСТ 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). В этот момент времени должны достигается важные результаты и приниматься критически важные решения для дальнейшей разработки.

Основными принципами RUP являются:

1. Итерационный и инкрементный (наращиваемый) подход к созданию программного обеспечения;

2. Планирование и управление проектом на основе функциональных требований к системе – вариантов использования;

3. Построение системы на базе архитектуры программного обеспечения.

Rational Unified Process поддерживает объектно-ориентированную технологию. Моделирование по методологии RUP является объектно-ориентированным и базируется на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), в качестве единого стандарта для организации взаимодействия участников проекта используют Unified Modelling Language™ (UML) — универсальный язык моделирования.

Важнейшие аспекты RUP

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

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

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

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

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

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

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

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

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

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

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

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

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