Представленные выше фазы укладываются в модель жизненного цикла, в которой обозначается их взаимосвязь, в том числе порядок их прохождения. Так, в каскадной (водопадной) модели предусмотрено строго последовательное выполнение этапов разработки программного продукта с началом последующего этапа только после завершения предыдущего и отсутствием какого-либо возврата на пройденные этапы. Такая схема хороша, если изначально удается составить абсолютно исчерпывающее техническое задание, которое не нужно будет уточнять в дальнейшем. Это возможно только при наличии должной квалификации не только исполнителя, но и заказчика, который должен досконально четко и в полной мере сформулировать требования к разрабатываемой программе. При разработке сколько-нибудь нового программного обеспечения поставить задачу на таком уровне достаточно тяжело, так как при этом необходимо учитывать все нюансы программной реализации, которые изначально могут быть неизвестны. Кроме того, в ходе работы над проектом требования заказчика могут измениться. Неполнота и непредвиденное изменение требований и спецификаций являются наиболее характерными проблемами при разработке программного обеспечения, о чем свидетельствует, в частности, отчет группы Standish Group по США [4]. Поэтому каскадная модель может оказаться слишком жесткой для реализации проекта.

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

§ Экстремальная (XP) разработка программного обеспечения.

Методика экстремального программирования XP (eXtreme Programming) сориентирована на группу с небольшим количеством (не более 10) высококвалифицированных программистов, которые приступают к разработке программного продукта с изначально неопределенными или часто меняющимися требованиями. Такая ситуация может возникнуть при задаче получения нового функционала, в реализации которого нет опыта, достаточного для постановки задачи на исчерпывающем уровне (см. §1.1).

Ключевыми концепциями экстремального программирования являются:

1. Постановка задачи только по определенным в настоящее время требованиям.

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

2. Проектирование максимально простой архитектуры продукта.

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

3. Максимально быстрое получение первой работающей версии программы.

Первая спецификация (пп. 1-2) должна быть сориентирована на разработку первого приближения к программному продукту в кратчайший срок.

4. Разработка на основе тестов.

Составляются тесты (см. §1.1), которые позволяют убедиться в работоспособности программы. Такие тесты пишутся как разработчиками, так и заказчиками.

5. Итерационное уточнение постановки задачи и архитектуры программы.

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

6. Систематические сборки с тестированием и отладкой.

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

7. Частая подготовка промежуточных версий продукта.

Сразу после выпуска первой версии (п. 3) и выполнения п. 5 начинается работа по разработке следующей версии программы, которая должна появиться как можно скорее. Временные интервалы между версиями должны быть сокращены до минимума.

8. Регулярная переработка (рефакторинг) кода.

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

9. Программирование в паре.

1

Программная реализация каждого выделенного фрагмента поставленной задачи (см. §1.1) выполняется двумя программистами. Один из них занимается непосредственно кодированием, тогда как второй анализирует его работу, оценивая и проверяя выбранные алгоритмы и их реализацию, предлагая более эффективные решения, отслеживая качество кода и т. д.

10. Соблюдение единого стандарта кодирования.

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

11. Взаимодействие с заказчиком.

Группа должна получать ответы на вопросы, возникающие в ходе разработки, для уточнения постановки задачи (п. 5), и иметь обратную реакцию от заказчика на результаты своей работы (п. 7).

Экстремальное программирование отличается большой гибкостью, динамичностью, высоким качеством многократно отлаживаемого кода, а также минимальным объемом сопроводительной документации и снятием соответствующей нагрузки по ее составлению. В то же время такой подход трудоемок вследствие частого выполнения тестирования, отладки и рефакторинга, а также плохо поддается планированию с точки зрения определения конечного срока сдачи проекта. Примером неудачной попытки использования такой стратегии является широко известный проект C3 по разработке системы учета выплат (Chrysler Comprehensive Compensation System) [3], который был запущен в 1995 году и был закрыт в 2000 году в связи с выходом за рамки бюджета и временных ограничений. Таким образом, если требования к проекту могут быть сформулированы достаточно исчерпывающим образом, имеет смысл прибегать к более надежной стратегии разработки. Образец такой стратегии (RUP) рассматривается в следующем параграфе.

§ Унифицированная разработка (RUP) программного обеспечения.

В данном параграфе рассмотрим такую технологию разработки программного обеспечения, как Rational Unified Process или сокращенно RUP. Эта технология используется для многоуровневого детального описания всех аспектов и этапов разработки программного обеспечения. Конечной целью является максимальная локализации постановки задачи для программиста (кодера), причем эта задача должна быть поставлена настолько понятно и досконально, насколько это вообще возможно. Для обеспечения понятности и необходимой детализации используются такие инструменты, как Rational Rose, который рассматривается в главе 2. Благодаря такому подходу с программиста снимается довольно большая нагрузка и ответственность, а также закладывается возможность реализации проекта с использованием обычных среднестатистических программистов без требования их высокой квалификации, как при экстремальном программировании.

Технология RUP сориентирована на итерационное создание архитектуры программного продукта в виде графических моделей формата UML. Функциональные требования выражаются в так называемых сценариях использования (Use Cases), которые отображают необходимое взаимодействие программы с пользователями или сторонними объектами.

Модель жизненного цикла RUP включает в себя такие четыре последовательно выполняемые фазы, как [3]: начальная фаза (Inception); фаза уточнения (Elaboration); фаза реализации (Construction); фаза внедрения (Transition).

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

1. Определение требований.

Детализируется спецификация проекта (см. §1.1) с той особенностью, что требования к функциональным возможностям программы описываются в виде сценариев использования на диаграмме сценариев (Use Case Diagram). К примеру, работа с Интернет-магазином по продаже автомобильных комплектующих (аналогичного www.exist.ru) раскладывается на такие операции со стороны пользователя, как поиск детали, помещение детали в корзину для покупок, редактирование корзины (удаление деталей и изменение их количества) и, наконец, оформление заказа с выбором способа оплаты. При этом последний сценарий можно разделить на два, а именно оформление заказа и выбор способа оплаты, но при этом между ними необходимо установить такую связь, чтобы при оформлении заказа всегда или при определенных условиях (в зависимости от схемы работы магазина) выбирался бы способ оплаты. Так, если в первый раз на www.exist.ru выбирается оплата наличными, то и при последующих заказах на сайте по умолчанию всегда будет предлагаться именно этот вариант. Если же клиент захочет воспользоваться другой схемой перечисления денег, то сможет это сделать, воспользовавшись предусмотренной функцией. Соответствующая связь между сценариями в терминологии UML называется связью расширения (extends), и при установлении этой связи подключаемый такой связью сценарий будет вызваться в ходе работы расширяемого сценария только при определенных условиях. Если

2

подключаемый сценарий должен вызываться в любом случае, необходимо установить связь включения (includes). Обычная связь называется ассоциативной связью (association). Рассмотренная функциональность Интернет-магазина может быть отображена на диаграмме сценариев Rational Rose следующим образом:

Рис.1. Диаграмма сценариев работы клиента с Интернет-магазином.

2. Анализ и проектирование.

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

2.1.Каждому сценарию использования сопоставляется диаграмма последовательности действий сценария (Sequence Diagram), которая передает все действия в рамках данного сценария в виде обмена сообщениями между структурными компонентами (объектами), причем этот обмен на диаграмме упорядочен по времени передачи сообщений. Для представления связей между объектами строятся диаграммы взаимодействия (Collaboration Diagram). Также создаются диаграммы состояний (Statechart Diagram), на каждой из которых отображаются состояния выбранного объекта и переходы между ними.

2.2.С выделенными объектами связываются классы с определением атрибутов и операций. Классы отображаются на диаграмме классов (Class Diagram) и подразделяются на:

информационные (Entity) классы, в которые группируются обрабатываемые данные;

интерфейсные (Boundary) классы, соответствующие механизмам передачи данных;

управленческие (Control) классы, операции которых используются для преобразования данных и управления ими.

Скажем, для рассмотренной выше части Интернет-магазина можно было бы выделить:

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

информационный класс данных по корзине;

информационный класс данных по заказу;

интерфейсный класс, позволяющий инициировать поиск детали;

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

интерфейсный класс, позволяющий как изменить содержимое корзины, так и перейти (из корзины) к оформлению заказа;

интерфейсный класс выбора способа оплаты;

интерфейсный класс оформления заказа;

управленческий класс поиска детали с формированием выходных данных по ней;

управленческий класс преобразования данных из корзины в данные по заказу.

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

2.3.С созданными классами соотносятся компоненты реализации программного продукта на диаграмме компонентов (Component Diagram).

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

3