3. План работ - позволяет определить ресурсы проекта, привязать их к задачам и рассчитать бюджет проекта. Таким образом, имеется возможность заранее спрогнозировать, насколько выгодно вести конкретный проект и какие могут быть при этом затраты.
4. Анализ рисков - важен потому, что обычно намного легче и дешевле выявить и устранить возможные проблемы заранее, чем делать это уже на поздних стадиях проекта.
5. Гибкая и надежная архитектура системы - гарантирует, что проект не потерпит крушение задолго до его завершения, что разработчики смогут развивать данную систему при изменении условий и правил ведения бизнеса на стороне заказчика.
6. Управление запросами на изменения - позволяет организовать эффективную работу и взаимодействие участников проекта. Возрастает контроль за качеством выполнения задания любого уровня, отслеживанием устранения ошибок и обработки предложений по дальнейшему развитию ИС.
7. Тестирование - дает возможность гарантировать высокое качество продукта, а, следовательно, не даст заказчику повод усомниться в возможностях организации-разработчика.
8. Акцент на самом продукте - крайне важен, потому что продукт — конечная цель любого проекта. Надо помнить в любой момент, что важны не модели или многочисленные документы проекта сами по себе, а именно конечный продукт. Все остальное создается только с тем, чтобы как можно скорее создать качественный продукт.
9. Документы для поддержки пользователя - необходимы, т. к. без них многие сильные стороны созданного продукта могут остаться неизвестными и недоступными.
10. Измерение проекта - в любой момент времени необходимо вовремя реагировать на возможные отклонения проекта от бюджета и на перерасход ресурсов.
Язык UML и его особенности
Инструментальные CASE-средства и диапазон их практического применения в большой степени зависят от удачного определения семантики и нотации соответствующего языка моделирования. Специфика языка UML заключается в том, что он определяет семантическую метамодель, а не модель конкретного интерфейса и способы представления или реализации компонентов.
Язык UML ориентирован для применения в качестве языка моделирования различными пользователями и научными сообществами для решения широкого класса задач ООАП. Многие специалисты по методологии, организации и поставщики инструментальных средств обязались использовать язык в своих разработках. При этом термин "унифицированный" в названии UML не является случайным и имеет два аспекта. С одной стороны, он фактически устраняет многие из несущественных различий между известными ранее языками моделирования и методиками построения диаграмм. С другой стороны, создает предпосылки для унификации различных моделей и этапов их разработки для широкого класса систем, не только программного обеспечения, но и бизнес-процессов. Семантика языка UML определена таким образом, что она не является препятствием для последующих усовершенствований при появлении новых концепций моделирования.
Унифицированный язык моделирования (UML) является стандартным инструментом для создания "чертежей" программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем.
UML подходит для моделирования любых систем: от информационных систем масштаба предприятия до распределенных web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. Изучение UML удобнее всего начать с его концептуальной модели, которая включает в себя три основных элемента: базовые строительные блоки, правила, определяющие, как эти блоки могут сочетаться между собой, и некоторые общие механизмы языка.
Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, скажем, документооборот в юридических системах, структуру и функционирование системы обслуживания пациентов в больницах, осуществлять проектирование аппаратных средств.
Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма - в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной (очень редко). Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы.
Таким образом, в UML выделяют девять типов диаграмм:
- диаграммы классов;
- диаграммы объектов;
- диаграммы прецедентов;
- диаграммы последовательностей;
- диаграммы кооперации;
- диаграммы состояний;
- диаграммы действий;
- диаграммы компонентов;
- диаграммы развертывания.
Наиболее распространенными средствами проектирования, поддерживающими язык UML и объектно-ориентированный подход, являются:
- Rational Rose – мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта является возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.
- Microsoft Office Visio – это решение для создания технических и деловых диаграмм, предназначенных для систематизации и наглядного представления различных данных, процессов и систем. Данный продукт позволяет специалистам технических и коммерческих направлений визуализировать свои идеи, информацию и проекты. Диаграммы Microsoft Office Visio позволяют без труда осуществлять визуализацию и обмен различной информацией с высочайшей точностью, надежностью и эффективностью, недостижимыми при использовании текстовых и числовых данных.
- Borland Together Architect представляет собой платформу визуального моделирования, предназначенную для архитекторов, проектировщиков, UML-дизайнеров, аналитиков бизнес-процессов и разработчиков моделей данных и позволяющую ускорить разработку высококачественного программного обеспечения. Together Architect помогает разработчикам лучше использовать информацию, получаемую от экономистов и лиц, определяющих и комментирующих требования к разрабатываемому программному обеспечению. Данное решение позволяет создавать модели UML и модели бизнес-процессов для генерации языка выполнения бизнес-процессов с возможностью описания web-сервисов. Повышает производительность и качество путем автоматизации отображения структуры и кода приложения с использованием аудита и метрик на уровнях моделей и кода.
Составим таблицу, в которой с помощью метода бальных оценок определим наиболее подходящее инструментальное средство проектирования, согласно критериям доступности, требования к ресурсам и удобства интерфейса:
Таблица 2.2. Сравнительный анализ средств проектирования
| Критерии выбора | Rational Rose | Microsoft Office Visio | Borland Together | Вес |
| Доступность | 3 | 5 | 3 | 3 |
| Требования к ресурсам | 5 | 4 | 3 | 1 |
| Удобство интерфейса | 4 | 5 | 3 | 2 |
| Итого: | 22 | 29 | 18 |
Итак, в соответствии с проведенным анализом, в качестве средства проектирования используется Microsoft Office Visio.
Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения.
Системная архитектура является, пожалуй, наиболее важным артефактом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем протяжении ее жизненного цикла.
Архитектура - это совокупность существенных решений касательно:
- организации программной системы;
- выбора структурных элементов, составляющих систему, и их интерфейсов;
- поведения этих элементов, специфицированного в кооперациях с другими элементами;
- составления из этих структурных и поведенческих элементов все более и более крупных подсистем;
- архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способ их объединения.
Моделью называется семантически замкнутая абстракция системы. Модель строится для того, чтобы лучше понимать разрабатываемую систему.
Моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме, так называемой диаграммы вариантов использования (Use Case Diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.
Диаграммы вариантов использования показывают взаимодействия между вариантами использования и действующими лицами, отражая функциональные требования к системе с точки зрения пользователя. Цель построения диаграмм вариантов использования – это документирование функциональных требований в самом общем виде, поэтому они должны быть предельно простыми.