18. Основные принципы организации процесса разработки по по rup.

Rational Unified Process – это процесс разработки программного обеспечения, соз­данный и распространяемый корпорацией Rational Software. Это – упорядоченный подход к распределению задач и обязанностей в организации-разработчике и управ­лению ими. Цель этого процесса – создать в рамках прогнозируемого бюджета и гра­фика работ программное обеспечение высокого качества, отвечающее требованиям конечного пользователя.

В Rational Unified Process собраны многие из лучших методов организации произ­водственных работ в современной области разработки программного обеспечения. Эти методы представлены в адаптируемой форме, подходящей для множества проек­тов и организаций Rational Unified Process оперативно доносит все указанные мето­ды к проектной группе, причем делает это в достаточно удобной форме.

Различные проекты разработки программного обеспечения терпят неудачу (к сожа­лению, ''провалом" заканчивают слишком многие). Мы можем выделить несколько основных показателей, характеризующих "провал" проектов¹.

• Неточное понимание нужд конечных пользователей

• Неспособность работы в условиях меняющихся требований

• Продукт состоит из несовместимых модулей

• Программное обеспечение трудно поддерживать или расширять

• Позднее обнаружение существенных изъянов проекта

• Плохое качество программного обеспечения

• Неприемлемая производительность

• Каждый сотрудник занимается чем-то своим, причем непонятно, кто, когда, где и зачем что-либо меняет

• Ненадежный процесс создания-выпуска

Хотя различные проекты "проваливаются" по различным причинам, похоже, что большинство неудам происходит вследствие сочетания следующих основных причин.

• Неумелое управление специальными требованиями

• Неопределенная и неточная связь

• "Хрупкая" архитектура

• Чрезмерная сложность

• Необнаруженные противоречия в требованиях, проектах и реализациях

• Недостаточное тестирование

• Субъективная оценка состояния проекта

• Неспособность справиться с реализовавшимся риском

• Неуправляемое распространение изменений

• Недостаточная автоматизация

Как лучше всего организовать процесс разработки

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

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

Итак, предлагаемые советы по органи­зации производственных процессов можно сформулировать следующим образом:

1. Разрабатывайте итеративно

2. Управляйте требованиями

3. Пользуйтесь модульными архитектурами

4. Используйте визуальное моделирование

5. Не забывайте о проверке качества

6. Следите за изменениями

Разрабатывайте итеративно

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

Основной проблемой описанного подхода является рост риска со временем; так что устранять ошибки предыдущих фаз становится слишком дорого. Первоначальный проект, наверняка, будет иметь изъяны в ключевых требованиях, и, более того, позд­нее обнаружение проектных недоработок может привести к перерасходу средств или отказу от проекта. Как сказал Том Гилб (Tom Gilb): “Если вы активно не нападете на риски вашего проекта, они активно нападут на вас”. Водопадный подход имеет тен­денцию к «маскировке» действительных рисков до тех пор, пока не будет слишком поздно на них реагировать.

Рис.1.1 Водопадный жизненный цикл.

Альтернативой водопадному подходу является поэлементный итеративный процесс, показанный на рис. 1.2. При таком подходе, основанном ни спиральной модели Барри Боема (Barry Boehm) , установление рисков, угрожающих проекту, осуществляется на более ранних этапах жизненного цикла, когда еще можно эффективно и своевременно реагировать на них. С помощью данного подхода осуществляется непрерывное обнару­жение, исследование и реализация, причем при каждой итерации группа разработчиков управляет артефактами проекта в целях их постепенного сближения.

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

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

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

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

4. Непрерывное итеративное тестирование позволяет объективно оценить состояние проекта.

5. Противоречия в требованиях, проектах и реализациях выявляются раньше.

6. Нагрузка команды (особенно команды тестирования) возрастает по мере раз­вития проекта.

7. Команда может обучаться и вследствие этого непрерывно улучшать процесс.

8. На протяжении всего жизненного цикла проекта его организаторы могут получать реальное представление о текущем состоянии проекта.

Рис.1.2 Поэлементный итеративный процесс

Управляйте требованиями

Сложность управления требованиями преимущественно программных систем состо­ит в динамичности этих требований; стоит ожидать, что в процессе развития проекта они изменятся. Более того, определение действительных требований системы – не­обходимых для достижения экономических и технических целей системы – является непрерывным процессом. Целиком определить системные требования до начала процесса разработки можно только для тривиальных систем. Действительно, при ви­доизменениях новой или модернизированной системы меняется и понимание поль­зователем требований к ней.

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

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

1. Управление требованиями позволяет упорядочить процесс разработки программного обеспечения.

2. Связь основывается на определенных требованиях.

3. Требования могут располагаться в соответствии с приоритетами; кроме того, их можно отфильтровать и отследить.

4. Возможна, объективна оценка функциональных возможностей и производительности.

5. Противоречия выявляются на более ранних этапах проекта.

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

Пользуйтесь модульными архитектурами

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

Системная архитектура включает решения относительно

• Организации программной системы;

• Выбора структурных элементов и их интерфейсов при формировании системы;

• Поведения этих структурных элементов, обусловленного совместной их работой;

• Формирования из структурных элементов и линий их поведения постепенно укрупняющихся подсистем;

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

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

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

Важным подходом к архитектуре программного обеспечения является модульная разработка (component-based development— CBD), позволяющая повторно использо­вать или настраивать компоненты из множества коммерчески доступных источников. Модель компонентных объектов (component object model — СОМ) корпорации Micro­soft, архитектура CORBA (Common Object Request Broker Architecture) группы Object Management Group и Enterprise JavaBeans (EJB) от компании Sun Microsystems – вот примеры распространенных и широко поддерживаемых платформ, на которых мо­жет использоваться модульная архитектура. Как показано на рис.1.3, компоненты де­лают возможным повторное использование в значительных масштабах, позволяют системам складываться из существующих частей, готовых частей от сторонних про­изводителей и нескольких новых, которые относятся к определенным областям и объединяют остальные части.

Рис. 1.3. Модульная архитектура программного обеспечения

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

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

1. Модули способствуют эластичности архитектуры.

2. При внесении изменений модульная структура позволяет явно разделить обязанности между элементами системы.

3. Благодаря стандартизованным конструкциям (таким, как СОМ+, CORBA и EJB) и коммерчески доступным компонентам возможно повторное использование системы.

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

5. Средства визуального моделирования автоматизируют модульную разработку.

Используйте визуальное моделирование

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

Рис. 1.4. Моделирование системы с различных точек зрения

Моделирование — это важно, поскольку оно помогает команде разработчиков визуализировать, определять, создавать и документировать структуру и поведение архи­тектуры системы. Использование стандартного языка моделирования, такого как UML (Unified Model Language — унифицированный язык моделирования), позволяет членам команды разработчиков однозначно доносить свои решения друг другу.

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

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

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

1. Прецеденты и сценарии однозначно определяют (от линии поведения).

2. Модели однозначно фиксируют структуру программного обеспечения.

3. Выявляются немодульные и неэластичные архитектуры.

4. При необходимости можно скрыть подробности.

5. В однозначных проектах более явно видны противоречия.

6. Качественные приложения начинается с хорошего проекта.

7. Средства визуального моделирования поддерживают моделирование на языке UML

Не забывайте о проверке качества

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

Рис. 1.5. Цена исправления ошибок

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

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

1. Состояние проекта оценивается объективно, а не субъективно, поскольку оце­ниваются результаты тестов, а не то, что написано на бумаге.

2. Эта объективная оценка показывает противоречия в требованиях, проектах и реализациях.

3. Тестирование и контроль сосредоточены в областях наибольшего риска; следовательно, в этих областях повышается качество и эффективность системы.

4. Дефекты выявляются на более ранних этапах, что значительно снижает стоимость их исправления.

5. Автоматизированные средства тестирования позволяют тестировать функцио­нальные возможности, надежность и производительность системы.

Следите за изменениями

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

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

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

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

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

• Запросы на внесение изменений способствуют установлению более надежной связи между группами разработчиков и заинтересованными сторонами.

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

• Сбор статистических данных позволяет объективно оценить состояние проекта.

• Рабочие среды содержат все артефакты, согласовывающие процесс.

• Распространение изменений поддается оценке и контролю.

• Изменения можно поддерживать в устойчивых, настраиваемых системах.

Существует четыре функции процесса разработки программного обеспечения.

1. Обеспечивать руководство последовательностью действий команды.

2. Определять, какие артефакты должны создаваться и когда.

3. Указывать, чем должны заниматься отдельные разработчики и целые команды.

4. Предлагать критерии наблюдения и измерения продуктов и видов деятельно­сти проекта.

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