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

Язык UML и его особенности

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

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

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

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

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

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

Таким образом, в UML выделяют девять типов диаграмм:

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

§ диаграммы объектов;

§ диаграммы прецедентов;

§ диаграммы последовательностей;

§ диаграммы кооперации;

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

§ диаграммы действий;

§ диаграммы компонентов;

§ диаграммы развертывания.

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

Наиболее распространенными средствами проектирования, поддерживающими язык UML и объектно-ориентированный подход, являются:

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

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

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

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9