Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

532 Глава 11

На уровне организации учет текущего и желаемого состояния знаний, умений

и способностей выполняется аналогично инвентаризации всех других ресурсов

предприятия при планировании его архитектуры и составлении плана корпоратив-

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

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

правильно упорядочивать проекты и предусматривать своевременное достижение

специалистами необходимого профессионального уровня.

На уровне проектных групп и отдельных сотрудников управление подготов-

кой рассматривается в рамках моделей процессов и проектной группы MSF.

Дисциплина управления подготовкой MSF включает в себя итеративный и

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

го для создания и управления проектами и решениями уровня знаний, умений и

способностей. Этот процесс состоит из четырех шагов: определение, оценивание,

корректировка и осмысление знаний и опыта. В рассматриваемом документе эти

шаги описаны детально.

Помимо описания методологии MSF в представленных выше документах

корпорация Microsoft предоставляет множество шаблонов проектных документов

для всех пяти фаз цикла создания решений. Они доступны в Интернет, например,

по адресам:

•

http://www.microsoft.com/downloads/details.aspx?FamilyId=9D2016AD-

6F8A-47F5-84FA-BEC389DB18C1&displaylang=en или

•

www.khsu.ru/trpp/Templates.zip (на английском языке).

11.6.6. Сравнение методологий RUP и MSF

Методологии RUP и MSF широко распространены в Украине и интерес к ним

продолжает возрастать по мере повышения уровня зрелости организаций-

разработчиков ПС. Они имеют много общих свойств и отличительных особенно-

стей. Для того чтобы быстро сориентироваться в возможностях MSF и RUP, мы

сопоставили их в таблице 11.9.

Таблица 11.9. Сравнение

методологий RUP и MSF

Критерий сравнения MSF RUP

Сфера рынка В основном, свободно

распространяемые про-

дукты, Web-сайты

Проекты на заказ. Не

Web-сайты

Масштаб и сложность Компактнее, проще в

применении. Нет ряда

руководств, которые, од-

нако, могут добавляться

самостоятельно. Более

пригодна для малых

краткосрочных проектов

Масштабнее. Множе-

ство руководств. Од-

нако сложнее изу-

чать, адаптировать.

Более пригодна для

крупных продолжи-

тельных проектов

Масштабирование Да Да. Сложнее

Инструментальная поддержка,

включая плагины для .NET

В основном «ручная»

методология

Инструменты для

всего ЖЦ.

Стоимость Только курсов и руко-

водств

Оплата за каждую

лицензию

С 2005 года методология поддерживается семейством Microsoft Visual Studio 2005

Глава 11 533

Критерий сравнения MSF RUP

Поддержка пользователей Нет Да

Итеративный подход Да Да

Количество фаз 5 4

Пофазовое сопоставление:

1 Выработка концепции Начало

2 Планирование Проработка

3 Разработка Построение

4 Стабилизация Передача

5 Развертывание Передача

Наличие руководств:

- по моделированию деловых

процессов

Нет Да

- по требованиям Кратко Детально

- по анализу и проектированию Кратко Детально

- по реализации Нет Да

- по тестированию Нет Да

- по внедрению продуктов Нет Да

- по управлению изменениями Нет Да

- по управлению проектами Кратко Детально

- по среде разработки Нет Да

- по интервьюированию Нет Да

- по использованию UML Нет Да

Количество шаблонов (форм) Не предопределено 42 предопределенных

Интеграция UML Может поддерживаться Встроен

Управление рисками Детальное Детальное

Ориентация на вехи проекта Да Да

Независимость от языка Да Да

Использование матрицы ком-

промиссов для выбора стратегии

Да Нет

Количество ролей в командах 6 5 основных. 31 вспо-

могательная

Роль менеджера проекта Разделяется на две Не разделяется

11.7. Процессы разработки в Agile-методологиях

11.7.1. Манифест Agile Alliance

В современных условиях рынка сфера применения классических «монолит-

ных» методологий создания ПС (ориентированных на постоянные требования к

продукту, фиксированные стоимость и сроки работ, а также продолжительный ЖЦ

с развернутым «полнокровным» процессом программной инженерии) постепенно

сужается, ограничиваясь преимущественно крупномасштабными государственным

программами. Вкладывая значительные средства в программные проекты, заказчи-

ки не намерены длительно ожидать реальных результатов, поскольку даже посто-

янство требований не гарантирует их надлежащей реализации.

Поиск и оформление новых подходов к разработке ПС взяли на себя специа-

листы-практики и независимые эксперты в области программной инженерии, среди

которых Кент Бек (Kent Beck), Мартин Фаулер (Martin Folwer), Кен Шваубер (Ken

Schwaber), Джефф Сазерленд (Jeff Sutherland) и другие. В 2001 они образовали не-

534 Глава 11

коммерческую организацию Agile Alliance

, пропагандирующую принципы уско-

ренной дробной «активной» разработки ПС (Agile Software Development), основан-

ной на методологиях eXtreme Programming, SCRUM, Dynamic Systems Development

Method (DSDM), Adaptive Software Development, Crystal, Feature-Driven

Development, Pragmatic Programming и др.[26].

Специалисты пришли к выводу, что лучшие подходы к созданию ПС нужно

искать, непосредственно активно участвуя в процессе разработки и помогая дру-

гим. В принятом ими Agile-Манифесте говориться [27]:

«Мы придерживаемся следующих принципов:

• Наивысшим приоритетом является удовлетворенность заказчика ранними

и периодическими поставками ценного для заказчика ПО.

• Приветствуйте изменения требований даже на поздних этапах разработки.

Agile-процессы готовы к таким изменениям ради достижения заказчиком конку-

рентного преимущества.

• Выполняйте частые поставки работающего ПО. Продолжительность каж-

дой итерации - от пары недель до пары месяцев, предпочтение отдается коротким

интервалам.

• Потенциальные пользователи системы, являющиеся специалистами в

предметной области, и разработчики должны работать вместе каждый день на про-

тяжении всего проекта.

• Привлекайте для работы над проектом мотивированных людей. Создайте

для них все условия, окажите поддержку во всем, что необходимо, и доверьтесь им

– они выполнят работу.

• Самый действенный и эффективный способ обмена информацией как

внутри команды разработчиков, так и разработчиков с внешним миром – непосред-

ственное общение.

• Работающее ПО – главный индикатор продвижения проекта.

• Agile-процессы придерживаются равномерного темпа разработки. Работа

спонсоров, разработчиков и пользователей должна все время идти в постоянном

темпе.

• Постоянное стремление к техническому совершенству и хороший дизайн

системы повышают agility.

• Важна простота – искусство увеличения объема работ, которых удалось

избежать.

• Самые лучшие архитектуры, требования и дизайны систем создаются са-

моорганизующимися командами.

• Периодически команда размышляет о том, как достичь большей эффек-

тивности, после чего корректирует свой подход к разработке ПО.»

Таким образом, методологии Agile ориентированы на тесное взаимодействие

команды разработчиков с пользователями, итеративную модель ЖЦ с прираще-

ниями и быструю реакцию на изменяющиеся требования, что предполагает высо-

кий профессионализм всех участников проекта. В основе этих методологий лежит

метод «суженной» разработки (LSD) уже упоминавшийся в п. 11.4.1. Хотя в целом

Адрес специализированного сайта Agile- (Эджейл-) Альянса в Интернете:

www.agilealliance.org

Глава 11 535

эти методологии придерживаются скорее «продукто-ориентированного», а не

«процессного» подхода к разработке, в них используются элементы гибких ТЛ и

«облегченных» процессов.

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

венных условий разработки ПС, обусловлена тем, что во главу угла каждой итера-

ции разработки ставится понятие ее «ценности для дела» (business value), как функ-

ции вложенных затрат, объема функциональности поставляемого фрагмента ПС,

времени выполнения работы и качества этого фрагмента ПС. Такой подход к раз-

работке ПС обеспечивает уменьшение зависимости не только от постоянных изме-

нений функциональных требований заказчика, но и от проблем неритмичности об-

щего финансирования и плана-графика разработки, а также, быстрой смены техно-

логической среды разработки.

11.7.2. Экстремальное программирование

Самой широко известной в Украине Agile-методологией является eXtreme

Programming (ХР) (экстремальное программирование) [28 - 33].

Основные принципы разработки в ХР и факторы ее ускорения таковы [34]:

• простота решений (реализация первого же принятого наипростейшего

решения, даже если оно сопряжено с риском),

• интенсивная итерационная разработка,

• парное программирование [35],

• малочисленные команды проектов (не больше 10 человек), активное об-

щение в команде и между командами,

• обратная связь с пользователем, который фактически вовлечен в процесс

разработки,

• «кураж» и желание идти на риск.

Один из самых известных приемов ХР, обеспечивающих качество ПО – пар-

ное (или совместное) программирование - процесс создания ПО двумя програм-

мистами, работающими бок о бок за одним компьютером (по схеме: один – пишет

код, другой - проверяет).

Исследования положительных и отрицательных сторон парного программи-

рования показали, что при таком подходе время разработки увеличивается на 15%,

однако улучшается дизайн системы, сокращается количество дефектов, снижается

риск, связанный с занятостью в проекте определенных сотрудников, растет про-

фессионализм членов команды, улучшается взаимодействие и коммуникация. Кро-

ме того, что не маловажно, сам процесс работы в целом доставляет гораздо больше

удовольствия [36]. Кроме парного программирования, в ХР пропагандируется

принцип «коллективного владения кодом», то есть любой член группы может из-

менить не только свой код, но и код другого программиста.

Другая важная особенность методологии ХР, обусловливающая качество –

стратегия тестирования ПО. Тесты создаются до написания кода, причем каждый

модуль снабжается автономным тестом (unit test), обеспечивая возможность рег-

рессионного тестирования модуля. Фактически тест определяет код, а не наоборот

(это вид разработки от тестов (или, основанной на тестировании) - test-driven

development, TDD) [32]. Функциональные тесты определяет заказчик (или аналитик

проекта с данной ролью). Тесты пишут сами программисты; любой программист

имеет право написать тест для любого модуля. Фрагмент кода образует часть вер-

536 Глава 11

сии тогда и только тогда, когда все тесты прошли успешно, в противном случае

данное изменение кода отвергается. Таким образом, большинство ошибок исправ-

ляются на стадии кодирования – либо путем просмотра кода (глава 6), либо путем

динамического тестирования (глава 7).

Основные практические приемы ХР подытожены в таблице 11.10.

Таблица 11.10. Основные практические приемы ХР

Практический прием Комментарий

Единая команда Коллективная работа и постоянное взаимодействие. Каж-

дый участник проекта считается членом команды с равны-

ми правами

Тесты заказчика Постоянное участие заказчика. Если реального заказчика

нет – на его роль назначается член группы (роль

“Customer”)

Небольшие релизы вер-

сий

Частая интеграция и выпуск небольших, но работающих

версий ПС

Циклы игрового плани-

рования

Планирование версий и итераций (состав, сроки, разработ-

чики). Сроки очень сжатые. Разбиение на осязаемые части

(в пределах недели-двух).

Коллективное владение

кодом

Любая пара программистов может в любой момент улуч-

шить любой код (не только свой). При работе с незнакомым

кодом один из членов команды выступает в роли эксперта.

Побочный эффект - приобретение знаний.

Метафоры Общее видение системы разрабатывается в форме простого

текстового описания, называемого метафорой (или набором

метафор). Используются единообразные обозначения, име-

нования и др., понятные всем членам команды.

Непрерывная интегра-

ция

Постоянно существует интегрированная версия системы.

Модули интегрируются после того, как прошли все тесты.

Стандарты кодирования Соблюдаются общепринятые стандарты кодирования, уста-

новленные в группе. Код должен быть понятен любому

Открытое рабочее про-

странство

Все программисты работают в одной большой комнате, ок-

руженной маленькими

Разработка от тестов

(Test-Driven Develop-

ment)

На каждой итерации выполняется автономное и функцио-

нальное тестирование. При этом достигается почти 100%

охват кода. Все тесты поддерживаются в актуальном со-

стоянии и должны работать в любой итерации и версии.

Программирование па-

рами

Программисты равноправны и работают попарно. Это га-

рантирует, что код проверен, и обеспечивает лучшее проек-

тирование, тестирование и кодирование.

Простой проект (про-

стые решения)

Сначала проектируется простая базовая архитектура систе-

мы, которая соответствует выбранной функциональности.

Развитие выполняется в ходе разработки.

Рефакторинг, перера-

ботка

Постоянное перепроектирование для улучшения проекта,

кода и снижения уровня сопряжений, а также как реакция

на изменения требований. Сопровождается тщательным

тестированием.

Поскольку в ХР велика роль человеческого фактора, важное значение имеет

распределение ролей в команде (таблица 11.11).

Глава 11 537

Таблица 11.11. Распределение ролей в команде ХР

Роль Обязанности

Заказчик (бизнес -

аналитик)

Определяет требования, планирует версии, устанавливает приоритеты

реализации, разрабатывает и выполняет функциональные (приемоч-

ные) тесты

Программисты Проектируют свою часть, пишут автономные тесты, кодируют, тес-

тируют, интегрируют. Помогают Заказчику реализовывать автомати-

зированные функциональные тесты

Тестировщики (не

всегда)

Помогают Заказчику определять функциональные тесты. Разрабаты-

вают планы тестирования и тестируют всю систему

Менеджеры (они

же аналитики)

Помогают определять требования, осуществляют внешнее взаимо-

действие и управляют проектом

Процесс разработки XP состоит из 3 фаз, представленных ниже:

Анализ концепции. Вначале выполняется анализ концепции программной

системы (как совокупности программных приложений), отражающей общее виде-

ние системы (называется метафорой). Цель – определить, что нужно делать, но не

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

возможных сценариев применений системы (внешних функций), над которыми со-

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

определенные задачи бизнеса, что позволяет ее протестировать и оценить с помо-

щью количественных показателей (сроков реализации).

Две следующие фазы разработки выполняются циклически.

Планирование. Осуществляется на двух уровнях (версии и итерации). Каса-

ется двух основных вопросов: прогнозирование сроков завершения одной версии и

итерации, и определение следующей.

1. Планирование версии. Заказчик определяет состав версии, упорядочивая

функции по важности, и представляет эти функции программистам, которые оце-

нивают их сложность (в терминах стоимости и сроков реализации). Заказчик, рас-

полагая этими оценками и зная важность характеристик, определяет примерный

план выпуска версий проекта. В плане устанавливаются приоритеты реализации

(хотя они могут и изменяться в процессе реализации). План регулярно пересматри-

вается и уточняется всеми членами команды разработки.

2. Планирование итерации. Каждая версия разбивается на итерации. Заказчик

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

Программисты дробят их на задачи (задача – это любая выполняемая работа) и

оценивают стоимость их реализации. Итерации планируются на 2 недели, по исте-

чении которых выбранная итерация должна работать. Основываясь на работах пре-

дыдущей итерации, группа решает, что можно успеть сделать в данной итерации.

Реализация. Цель каждой итерации – запустить в эксплуатацию несколько

новых протестированных и готовых к работе функций (историй). Реализуются

только истории, выбранные для текущей итерации.

Программисты проектируют и программируют очередную версию системы,

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

По мере завершения задач разработанный код интегрируется в общую вер-

сию системы и тестируется вместе с ней. При этом либо все тесты успешно прохо-

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

няется часто (возможно и несколько раз в день) по мере готовности модулей.

538 Глава 11

Заказчик, работая параллельно с программистами, определяет один или не-

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

использует их для функционального тестирования. К концу итерации все тесты для

отдельных модулей и все функциональные тесты должны работать. Эти тесты со-

храняются для последующего тестирования.

После завершения итерации начинается планирование следующей (выбира-

ются новые истории) и цикл продолжается до готовности полной версии системы.

После выпуска очередной версии выбираются следующие истории и т.д.

Архитектура системы постоянно эволюционирует, а текущий проект транс-

формируется, при условии сохранения гарантии правильного выполнения тестов.

Процесс XP в высшей степени неформален, но требует высокого уровня са-

модисциплины, в противном случае он мгновенно превращается в хаотичный и не-

контролируемый. Это процесс разработки с наиболее высокой степенью риска, по-

скольку другие методы снижения коммерческих рисков, кроме опоры на «челове-

ческий фактор», в XP просто отсутствуют [34].

11.7.3. Методология SCRUM

Другая, менее известная в Украине, Agile-методология разработки ПС -

SCRUM (дословно (в регби)– «схватка вокруг мяча») - гибкая методика управления

проектом фирмы Advanced Development Methods, Inc., представленная впервые в

1995 году. Ныне применяется в более чем 50 организациях, включая Fuji-Xerox,

Canon, Honda, NEC, Epson, Brother, 3M, Xerox and Hewlett-Packard и др.[37, 38].

В отличие от методологий, ориентированных на каскадную, спиральную или

итеративную модель ЖЦ, предполагающих фиксированный, четко определенный

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

(возможно, в цикле) - анализ требований, проектирование, программирование,

тестирование - SCRUM трактует процесс разработки как «черную коробку» с

контролируемыми параметрами. Фактически наблюдается смещение парадигмы

«определенный и повторяемый процесс» к парадигме - «контролируемый процесс».

SCRUM не требует «линейности» (внутри «коробки») и допускает, в зависи-

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

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

образом, преодолеваются три основных препятствия успешной разработки:

- требования определены изначально не четко и/или не полностью,

- требования изменяются в ходе проекта,

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

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

Для гибкого управления проектом с такими особенностями в SCRUM приме-

няются специальные методы (приемы) работы на стадиях проекта и механизмы

регуляции (рычаги регулирования) при управлении непредсказуемым процессом.

С самого начала проекта требования к ПС преобразуются в списки функций,

свойств или выполняемых работ, образуя Портфель заказов (Бэклог, Backlog).

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

за один день, что улучшает прослеживаемость хода проекта. Содержимое Портфеля

распределяется между командами проекта.

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

рает независимо от остальных, но всех игроков объединяет общая цель. В команде

Глава 11 539

– максимум 6 человек под руководством менеджера - Scrum-мастера, который

управляет «почти хаотическим» процессом работы по методологии SCRUM.

Все запланированное время выполнения проекта разбивается на периоды

продолжительностью 1 - 4 недели. В течение каждого периода, называемого

Спринтом (рывком, броском, от sprint), команды выполняют задачи, которые опре-

делены для них содержимым Портфеля (бэклог-задачи).

Каждый день в ходе Спринта команда проводит Совещание, продолжитель-

ностью до 15 минут, на котором обсуждается состояние выполнения бэклог-задач

каждого разработчика, а именно: завершенные работы (с момента предыдущего

совещания), незавершенные работы (которые будут сделаны до следующего сове-

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

ринга продвижения проекта.

Процесс программной инженерии включает три фазы (таблица 11.12).

Таблица 11.12. Фазы и действия в методологии SCRUM

Действие Задача Описание

Подготовительная фаза

Технологическая

подготовка

Определение стандартов разработки, их обзор, адаптация (раз-

работка соответствующих руководств, толкующих положения

стандартов), доведение стандартов до исполнителей.

Планирование

• Разработка списка задач в Портфель заказов проекта.

• Определение дат и объемов релизов (поставляемых компо-

нентов, версий, пакетов функций) продукта.

• Выбор релизов, подлежащих немедленной разработке.

• Отображение множества функций и свойств релиза в группу

записей Портфеля заказов, связанных с этим релизом.

• Определение команды (команд), которая будет разрабатывать

релиз (выполнять пакет всех работ, связанных с релизом).

• Оценивание риска и механизмов его устранения.

• Обзор и корректировка записей Портфеля и пакетов работ.

• Утверждение или решение об изменении инструментов раз-

работки и инфраструктуры.

• Оценка стоимости релиза, включая собственно разработку,

общесистемные работы, поставку и обучение.

• Верификация решений и обеспечение их реализации.

Архитектурное про-

ектирование

• Обзор записей Портфеля, связанных с релизом.

• Идентификация изменений, необходимых для реализации

задач в Портфеле.

• Анализ ПрО в объеме, необходимом для построения, разви-

тия или обновления моделей ПрО в соответствии с новым

системным контекстом и требованиями.

• Уточнение архитектуры системы в свете нового контекста

системы и требований.

• Идентификация любых проблем или задач, связанных с раз-

работкой или реализацией изменений.

• Обзорное совещание по проектным решениям, на котором

каждая команда представляет подход к решению задач из

Портфеля. При необходимости, перераспределение задач по

командам.

540 Глава 11

Действие Задача Описание

Фаза циклической параллельной итеративной разработки (Спринты)

Спринт

Итеративный цикл разработки. Руководство контролирует дос-

тижение требований по времени разработки, качеству или

функциональности продукта. По окончании всех итераций (всех

спринтов) наступает завершающая фаза проекта.

Разработка Определение изменений в продукте, которые необходимо про-

извести, чтобы решить задачи и удовлетворить требования, ука-

занные в записях Портфеля, оформив решения в виде пакетов

решений. Выполнение работы, включающих анализ ПрО, про-

ектирование, конструирование, реализацию, тестирование и

документирование изменений.

Компоновка Оформление изменений в виде пакетов решений, создание ис-

полняемой версии изменений и описание того, как они реали-

зуют требования, отраженные в записях Портфеля.

Просмотр Обзорное совещание всех команд, на котором разработчики

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

решают проблемы, добавляют новые записи в Портфель. Ана-

лиз действий, принятых по установленным факторам риска.

Уточнение Обобщение информации, полученной на обзорном совещании, в

виде соответствующих пакетов задач (требований), с отражени-

ем различных мнений и пожеланий, а также новых свойств.

Разбор Спринта

Анализ результатов Спринта

Просмотр

ПО

Просмотр продукта руководством проекта совместно с коман-

дой разработки. Присутствовать могут также заказчики, пользо-

ватели, покупатели, специалисты по продаже и др.

Проверка со-

ответствия

Портфелю

Рассмотрение функционирующих исполняемых подсистем

(компонентов), разработку которых осуществляла команда,

включая изменения, внесенные в связи с реализацией задач,

указанных в виде записей в Портфеле.

Корректи-

ровка записей

в Портфеле

При необходимости, как результат просмотра, корректировка

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

Добавление

записей в

портфель

Один из результатов проверки – внесение новых записей в

Портфель и их распределение по командам, что влечет за собой

содержательное изменение создаваемых релизов.

Планирование

следующих

проверок

Определение времени следующей проверки, исходя из состоя-

ния разработки и сложности задач. Обычная продолжитель-

ность Спринтов – от 1 до 4 недель.

Заключительная фаза

Когда руководство считает, что по времени, качеству, стоимо-

сти (затратам), соответствию требованиям и другим факторам

пора оформлять релиз для поставки, оно объявляет релиз «за-

крытым» и открывает заключительную фазу проекта.

В этой фазе разработанный продукт готовится к поставке. Вы-

полняются интеграция, системное тестирование, формирование

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

ментов по передаче продукта и др.

Первая фаза (подготовительная) и последняя фаза (заключительная) включа-

ют хорошо известные фиксированные процессы, в которых все действия, входы и

Глава 11 541

выходы четко определены. Поток работ линейный с некоторыми итерациями в под-

готовительной фазе.

Вторая фаза (фаза Спринтов) включает совокупность эмпирических процес-

сов, выполняемых циклически. Управление ими осуществляется только с помощью

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

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

разработки в Спринтерской фазе максимально гибкий, основанный на использова-

нии существующего опыта разработчиков и накоплении новых знаний методом

проб и ошибок при продвижении к завершению проекта.

Проект остается открытым для любых изменений (касающихся условий сре-

ды, сложности и качества поставляемого продукта, времени и финансирования) до

наступления Заключительной фазы.

Во избежание хаоса (непредсказуемости и сложности) в SCRUM определены

контролируемые объекты процесса и механизмы их контроля (таблица 11.13).

Таблица 11.13. Контролируемые объекты процесса разработки

Объект Описание

Портфель

(Backlog)

Описания функциональных требований (новых или неадекватно реа-

лизованных в существующем релизе) и задач, связанных с ошибками,

дефектами, запрошенными заказчиком расширениями, конкурирую-

щими функциями продукта, технологическим развитием и др.

Релиз/ Расши-

рение

(Release/ En-

hancement)

Содержимое Портфеля, которое в определенный момент времени в

совокупности представляет жизнеспособный прототип с позиций тре-

бований, периода времени, качества и др.

Пакеты про-

дукта

(Packets)

Компоненты продукта или другие объекты, которые должны быть

изменены для реализации задач из Портфеля в новом релизе.

Изменения

(Changes)

Изменения, которые должны быть внесены в пакет для реализации

задачи из Портфеля.

Проблемы

Problems

Возникшие технические проблемы, которые должны быть решены,

для того чтобы можно было реализовать изменения.

Риски

Risks

Непрерывно оцениваемые факторы риска (угрозы), с которыми связан

успех проекта. Результаты оценивания риска могут повлиять на выбор

контролируемых параметров процесса.

Решения

Solutions

Комплексные решения (пакеты решений) по проблемам и рискам, за-

частую приводящим к изменениям.

Вопросы

Issues

Артефакты проекта и вопросы, связанные с проектом, которые не оп-

ределены в терминах пакетов, изменений и проблем.

Базируясь на современной теории управления процессами, SCRUM обуслов-

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

проекта и в установленные сроки.

Методология SCRUM используется, с одной стороны, в качестве «оболочки»

для существующих процессов и применяемых приемов работы в организациях, и, с

другой стороны, как способ совершенствования этих процессов.

Одним из существенных недостатков SCRUM является то, что интеграцион-

ные и приемочные тесты не детализируются.

Подробнее о SCRUM можно узнать на Agile Software Development Portal по

адресу http://agile.csc.ncsu.edu.