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

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

552 Глава 11

В методологиях с каскадной моделью ЖЦ прогресс разработки измеряется в

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

дой стадии колеблется от нескольких месяцев до нескольких лет.

Сравнивая разные подходы к разработке ПС, Б.Боэм упорядочил их в по-

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

зрелости SW-СММ и CMMI [45] (рисунок 11.8).

Рис.11.8. Упорядочение методологий по строгости планирования

Хотя SW-CMM, разработанная в начале 90-х годов, изначально в большей

степени была ориентирована на плановые процессы, Б.Боэм предложил тракто-

вать ее шире, как охватывающую также современные итеративные процессы. Са-

ми авторы модели СММ также считают, что «либеральная», а не «консервативная»

трактовка СММ в целом позволяет охватить основные аспекты гибких методологий

[46]. В том же духе Б. Боэм предлагает интерпретировать и модель СММІ, в кото-

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

пами и организационной средой, что позволяет распространить CMMI и на Agile-

методологии.

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

ции на рынке программных продуктов, Б.Боэм пришел к выводу, что, несмотря на

устойчивую тенденцию перемещения акцентов в сторону «ускоренной» разработ-

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

подходы, комбинирующие «скорость» и «дисциплину».

Б.Боэм и Р.Торнер предложили метод анализа условий применения методо-

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

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

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

тов или организаций [47, 48].

11.9.2. Определение условий применения методологий разработки

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

ектам (Home Grounds’ Analysis) основан на схеме сопоставления характеристик

проектов и возможностей методологий по следующим четырем направлениям [48]:

1. Сфера применения: основные цели, размер и среда проекта.

2. Управление: отношения с заказчиком, планирование и контроль, взаимо-

действие.

3. Технические аспекты проекта: требования, разработка, тестирование;

4. Персонал: заказчики, разработчики, культура (сложившиеся традиции в

коллективе).

Глава 11 553

В таблице 11.17 приведены ключевые аспекты анализа по всем направлени-

ям, основные характеристики «ускоренных» процессов и предсказуемых (плано-

вых) процессов.

Таблица 11.17. Направления сравнения подходов

Основные характеристики Направ-

ление

Ключевые

аспекты

Ускоренные процессы Плановые процессы

Основные

цели

Быстрая демонстрация ре-

зультатов работы, реакция

на изменения:

- быстрая отдача от инве-

стиций в проект;

- быстрая реакция на требо-

вания рынка программных

продуктов.

Предсказуемость, стабиль-

ность, обеспечение гарантий:

- более «прозрачное» управ-

ление проектом, инвестиции в

процесс;

- долгосрочные инвестиции в

ПС;

- необходимость разработки

планов и большого объема

документации, соблюдения

стандартов (для критических

систем).

Размер

Небольшие группы и проекты Большие проекты и коллекти-

вы

Сфера

приме-

нения

проекта

Среда раз-

работки

Нестабильная, изменчивая:

- тесное взаимодействие раз-

работчиков и участие заказ-

чика.

Стабильная, слабо изменяю-

щаяся:

- разработка ПС по государст-

венным заказам, аутсорсинг,

распределенные проекты.

Отноше-

ния с за-

казчиком

Квалифицированные заказчи-

ки (при постоянном участии в

проекте), определяющие при-

оритеты реализуемых воз-

можностей ПС:

- доверие заказчиков (места на

рынке) поддерживается вы-

пуском работоспособных вер-

сий ПС;

- источником проблем может

стать взаимодействие между

заказчиком и разработчиками.

Отношения регулируются

условиями договора:

- доверие поддерживается от-

слеживанием рабочих продук-

тов в оговоренных точках

(сдачи этапов работ);

- источником проблем во

взаимоотношениях могут быть

условия договора.

Планиро-

вание и

контроль

Внутренние краткосрочные

планы, контроль на качест-

венном уровне:

Документированные долго-

срочные планы (на все этапы

проекта), контроль на количе-

ственном уровне

Управ-

ление

Взаимо-

действие

Неформальный обмен зна-

ниями:

- тесное взаимодействие раз-

работчиков;

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

код и тесты;

Посредством обмена и изуче-

ния документов:

- четкий процесс документи-

рования,

- наличие всех утвержденных

рабочих продуктов (планы,

требования, отчеты и т.д.),

554 Глава 11

Основные характеристики Направ-

ление

Ключевые

аспекты

Ускоренные процессы Плановые процессы

- улучшение процесса пу-

тем самосовершенствова-

ния (парное программиро-

вание, участие в коллек-

тивных проверках).

- улучшение процесса посредст-

вом изменения документирован-

ного процесса и доведение изме-

нений до исполнителей.

Требова-

ния

Приоритезированные за-

казчиком (пользователем)

неформальные требования

и тесты:

- функциональные тесты

составляют основную часть

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

заказчика.

Формализованные требования и

их обязательная оценка:

- больше внимания не функцио-

нальным требованиям.

Разработка Простой проект, короткие

циклы; легко выполнять

переработки и изменения:

- требования пользователя

могут оказаться сложнее,

чем ожидалось;

- переработки и изменения

также могут оказаться

сложными.

Большой подробный проект,

сложные переработки:

- большая доля затрат на разра-

ботку архитектуры ПС;

- возможность разработки по-

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

тов.

Техни-

ческие

аспекты

проекта

Тестиро-

вание

Функциональные требова-

ния определяются выпол-

нимыми тестами:

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

дульное и функциональное

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

Документированные тест-планы

и процедуры:

- позднее тестирование с акцен-

том на соответствие специфика-

циям

Заказчики Готовые к сотрудничеству,

представительные, полно-

мочные, знающие и квали-

фицированные заказчики,

постоянно участвующие в

проекте

Те же условия, но без постоянно-

го участия заказчика

Разработ-

чики

Очень высокие требования

к квалификации и владе-

нию методологией. Реко-

мендуемый состав группы

по уровням квалификации

(см. табл.11.18):

не менее 30% членов груп-

пы с уровнями 2 и 3, но не

1В, с полной занятостью.

Менее жесткие требования к

квалификации, учет времени на

обучение. Рекомендуемый состав

группы по уровням:

не менее 50% членов группы с

уровнем 3 (на ранних этапах

проекта с полной занятостью не

менее 10%), 30% на уровне 1В с

полной занятостью.

Персо-

нал

Культура Много степеней свободы,

приверженность принци-

пам методологии

Работа регламентирована рамка-

ми политик и процедур методо-

логии

Для оценки потребности в людских ресурсах и требований к квалификации

специалистов Б.Боем применяет шкалу оценивания, предложенную А.Кокборном в

[49] для ХР (таблица 11.18).

Глава 11 555

Таблица 11.18. Шкала оценивания квалификации персонала

в ХР

Уровень Характеристики

3 Способен изменить (пересмотреть) правила при возникновении неожиданной

беспрецедентной ситуации

2 Способен изменить (пересмотреть) правила при возникновении неожиданной

ситуации, у которой был прецедент

1А После обучения, способен выполнять отдельные шаги метода такие как: оцен-

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

(рефакторинг), сложная интеграция готовых продуктов (COTS). Со временем

может достичь уровня 2.

1В После обучения, способен выполнять отдельные процедуры метода такие как:

кодирование несложных задач, простые переработки (рефакторинг), соблюде-

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

опытом может достичь некоторых навыков уровня 1А.

-1 Может обладать нужной квалификацией, но не способен к взаимодействию

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

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

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

занным с ключевыми аспектами выделенных направлений анализа):

1. Размер – количество персонала.

2. Критичность – степень критичности продукта (для пользователя или по

безопасности).

3. Изменчивость проекта – частота изменения требований.

4. Культура – стиль руководства в организации.

5. Персонал – квалификация персонала.

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

ного применения методологии, а с другой (при несоответствии реальным услови-

ям проекта) – служат источниками риска срыва проекта.

Графическая интерпретация метода заключается в построении и анализе

полярной диаграммы, оси координат которой (в полярной системе координат)

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

По каждому фактору определены следующие количественные единицы из-

мерения:

•

Размер – количество ключевых участников проекта (не только разра-

ботчиков);

•

Критичность – оценка величины потерь из-за отказов в ПС:

1 – нарушение удобства применения, потери времени пользователя;

2 – потери репутации фирмы-потребителя, небольшие финансовые потери;

3 –значительные финансовые потери;

4 – потеря жизни (одной);

5 – потеря жизни (массово).

•

Изменчивость – скорость изменения требований, выраженная в % изме-

нений в месяц;

•

Культура – долевая оценка «хаоса» в работе - чем выше значения, тем

больше свободы действий и тем больше ответственности (оценки субъективные);

•

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

уровня 2 и 3 (в %).

556 Глава 11

Оценки для agile-методологий располагаются на графике ближе к центру

полярной диаграммы (небольшие значения), а для плановых – ближе к периферии

(большие значения). На рисунке 11.9 изображена полярная диаграмма, отражаю-

щая идеальный профиль применения Agile-методологий, а на рисунке 11.10 – иде-

альный профиль плановых.

Рис. 11.9. Идеальный профиль Agile-методологий

Рис. 11.10. Идеальный профиль плановых методологий

В таблице 11.19 подытожены идеальные условия применения методологий.

Можно заметить, что такие характеристики, как Изменчивость и Персонал,

ассиметричны.

Так, Agile-методологии в основном ориентированы на высокую скорость

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

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

не применимы.

Глава 11 557

Таблица 11.19. Идеальные условия применения методологий

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

Ускоренные Плановые

Размер Небольшой проект, менее 10 чело-

век

Большой проект (несколько лет, до

300 человек)

Критич-

ность

Важный, но не критичный (по стои-

мости или безопасности) проект

Критичный по безопасности

Изменчи-

вость

Высокая скорость изменения требо-

ваний (заказчики не могут четко

сформулировать потребности)

Низкая скорость изменения требо-

ваний, значительные затраты на

разработку подробных специфика-

ций требований

Культура Небольшая компания-разработчик,

четкая структура руководства, мно-

го степеней свободы

Иерархическая структура управле-

ния и контроля, работа четко рег-

ламентирована инструкциями.

Персонал Оптимальное сочетание квалифика-

ции разработчиков в команде

(уровня 2 и 3 по шкале Кокборна)

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

сокой квалификации в команде.

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

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

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

Порядок применение метода для оценки условий проектов таков.

1. Оценить условия проекта и среду по 5 критическим факторам.

2. Отобразить оценки на полярной диаграмме.

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

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

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

методологию.

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

профиль методологий оказывается смешанным. Например, на рисунке 11.11

пунктиром изображено смещение идеального agile-профиля проекта в сторону

планового по фактору «Размер», а на рисунке 11.12 – смещение планового про-

филя к agile-профилю по фактору «Изменчивость».

Рис. 11.11. Смещение agile-профиля в сторону планового

558 Глава 11

Рис. 11.12. Смещение планового профиля в сторону agile

Если реальные условия проекта не соответствуют идеальным, Б.Боэм и

Р.Торнер предложили оценивать риск применения каждой методологии по сле-

дующей схеме:

1. Идентифицировать источники риска:

• определить риск применения ускоренных процессов по источникам риска:

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

неадекватное применение принципа «простой проект»,

нехватка персонала требуемой квалификации;

• идентифицировать риск применения плановых процессов по источникам

риска:

быстрые изменения,

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

не стабильные требования,

нехватка персонала нужной квалификации.

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

ставлены в таблице 11.20.

Таблица 11.20. Критические факторы успеха и источники риска

Фактор Ускоренные процессы Плановые процессы

Размер Тесное взаимодействие и обмен

знаниями трудно обеспечить в

большом коллективе.

Избыточная бюрократия и трудность

настройки процесса для небольших

групп и проектов.

Критич-

ность

Не проверены для критичных

проектов, свободное проектиро-

вание и слабое документирова-

ние могут стать источником рис-

ка для заказчика

Пригодны для ПС, критических по

безопасности функционирования.

Могут быть избыточны для ПС, не яв-

ляющихся критическими.

Изменчи-

вость

проекта

В стабильной среде проекта та-

кие характеристики, как простой

проект и постоянные переработ-

ки, менее эффективны

Тщательное планирование и проектиро-

вание, применимые в стабильной среде,

могут оказаться избыточными и затрат-

ными, поскольку потребуют постоянно-

го контроля за изменениями.

Глава 11 559

Фактор Ускоренные процессы Плановые процессы

Культура «Выигрыш на хаосе». Персонал

имеет полномочия и счастлив

нести ответственность.

«Выигрыш на порядке». Роли персона-

ла, а также применимые процедуры

четко определены.

Персонал Достаточное количество персо-

нала нужной квалификации (с

уровнем 2 или 3) с полной заня-

тостью. Риск использовать пер-

сонал уровня 1В.

В начале проекта (для анализа и проек-

тирования) необходимо преобладание

персонала с уровнем 2 и 3, затем могут

добавляться специалисты уровня 1В.

2. Оценить рейтинг риска по 6 бальной шкале:

- минимальный,

- средний,

- серьезный, но контролируемый,

- очень серьезный, но контролируемый,

- постоянный (showstopper).

3. Уточнить оценки риска. Если при оценке рейтинга возникают затруднения

- собрать дополнительные данные (например, с помощью прототипирования или

выполнения «пилотного» проекта);

4. Принять решение:

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

ile, и наоборот;

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

коренную разработку, в иных ситуациях – плановую.

5. Выполнять проект (разработку ПС) по выбранной методологии.

6. Отслеживать прогресс, постоянно переоценивать риски и, в случае необ-

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

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

процессе разработки, что приведет к изменению профиля процесса.

Изменение agile-профиля в сторону планового. Может потребоваться, напри-

мер, при следующих условиях:

1. Проект изначально попадал под условия применения agile-методологии, но

оказался масштабнее, чем это ожидалось.

2. Проект изначально попадал под условия применения agile-методологии, но

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

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

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

ры ПС;

- более тщательное определение «вех» внутри итераций для улучшения

управления;

- применение шаблонов проектирования (или других архитектурных подхо-

дов) для того, чтобы избежать избыточной переработки и др.

Изменение планового профиля в сторону agile. Может потребоваться, напри-

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

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

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

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

скольку это требует изменения таких факторов, как культура и персонал. Действи-

560 Глава 11

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

ну менее директивного, и, во-вторых, - необходимость изменения профиля персо-

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

Анализируя разные методологии разработки и критические факторы их ус-

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

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

факторами в любых проектах остаются [50]:

- люди (что влечет за собой и необходимость осознания важности человече-

ского фактора - как разработчиков, так и заказчиков);

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

ления значимости ПС в целом и ее компонентов, приоритезацию требований и др.);

- взаимодействие (сотрудничество и взаимопонимание как разработчиков с

заказчиками, так и самих разработчиков);

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

можно! Необходимо быть готовым сузить область проекта).

Литература к главе 11

1. Лапидус В.А. Система Шухарта // материалы семинара «Всеобщее управление качест-

вом (TQM) и статистические методы» (Киев, 20-22 февраля 2001), Украинская ассоциа-

ция качества. Межотраслевой центр качества «ПРИРОСТ». – 2001. – 29 с.

2. Исикава К. Японские методы управления качеством. – М.: Экономика, 1988. – 216 с.

3. Кумэ Х. Статистические методы повышения качества. – М.: Финансы и статистика. –

1990. – 304 с.

4. Электронный учебник по промышленной статистике.- М., StatSoft, Inc. – 2001.

(www.statsoft.ru/home/portal/textbook_ind/default.htm)

5. Florac W.A., Carleton A.D. Statistical Process Control: Analyzing a Space Shuttle Onboard

Software Process // IEEE Software. - july/aug 2000. - P. 97 – 106.

6. Weller E.F. Practical Applications of Statistical Process Control // IEEE Software. - v.17. -

n.3, may/june, 2000. - P. 48 – 55.

7. Humphrey W.S., Snyder T.R., Willis R.R. Software process improvement at Hughes Aircraft

// IEEE Software. - v.8. - n.4, july/aug. – 1991. - P. 11 – 23.

8. BOOTSTRAP - http://www.cse.dcu.ie/essiscope/sm5/approach/boot-1.html

9. TRILLIUM - http://www.sqi.gu.edu.au/trillium/t3_toc.html

10. Лаврищева Е.М. Основы технологической подготовки разработки прикладных про-

грамм СОД // АН УССР, ИК им. В.М. Глушкова, Препринт 87-5. – Киев. – 1987. – 29 с.

11. Basili V.R. A Quantitative Approach to Software Management and Engineering //

www.cs.umd.edu/class/fall2001/cmsc735/introduction.pdf

12. Basili V.R., Green S. Software Process Evolution at the SEL // IEEE Software. - v.11. - n.4,

july/aug. – 1994. - P. 58 – 66

13. Basili V.R., Caldiera G., Rombach H.D. Experience Factory // Encyclopedia of Software En-

gineering (John J. Marciniak, ed.). - v. 1. – NY.: John Wiley Sons. – 1994. - P. 469 – 476.

14. Трофимов Сергей. Унифицированный процесс разработки от Rational Software //

«PCWeek/RE».- №4.- 2003 (а также, www.caseclub.ru/articles/rup2.html).

15. Закис А. RUP — знакомый незнакомец // «Открытые системы».- №4.-2004 (а также

www.osp.ru/text/302/184459.html).

Глава 11 561

16. Якобсон А., Буч Г., Рамбо Дж.Унифицированный процесс разработки программного

обеспечения / Спб.: Питер, 2002. - 496 с.

17. Трофимов Сергей. Рабочие процессы RUP и диаграммы UML //

http://www.caseclub.ru/articles/rup_uml.html

18. Kroll P. The Spirit of the RUP // www.ibm.com/developerworks/rational/library/ con-

tent/RationalEdge/dec01/TheSpiritoftheRUPDec01.pdf

19. Rational Unified Process http://www.interface.ru/rational/rup01_t.htm

20. Крачтен Ф. Введение в Rational Unified Process. — Изд. 2-e: Пер. с англ. // M.: Изда-

тельский дом “Вильямс”, 2002. — 240 с

21. Трофимов С.А. Rational XDE для Visual Studio .NET // М.: ООО «Бином-Пресс», 2004 г.

— 304 с

22. Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP для

практиков / М. «КУДИЦ-Образ», 2004. - 432 с.:

23. Бергстрем С., Роберг Л. Rational Unified Process – путь к успеху. Руководство по вне-

дрению RUP / М. «КУДИЦ-Образ», 2004. - 256 с.

24. Трофимов С.А. CASE-технологии: практическая работа в Rational Rose. 2-е издание //

М.: «Бином-пресс», 2002, 288 с.

25. Хаф Л. Методология разработки ПО. Часть 5. Microsoft Solutions Framework // Компью-

тер Пресс.-№7.-2004 (а также www.compress.ru/Archive/CP/2004/7/29/)

26. История манифеста Agile // agilemanifesto.org.ru/history.html.

27. Принципы, лежащие в основе манифеста Agile // agilemanifesto.org.ru/principles.html

28. Martin R.C. Extreme Programming development through dialog // IEEE Software. - july/aug

2000. - P. 12 - 13

29. Бек К. Экстремальное программирование» // Открытые системы. – N. 1-2. – 2000. - с. 59

– 65.

30. Бек К. Экстремальное программирование. Библиотека программиста. С.-Петербург:

Питер. – 2001. – 224 с.

31. Бек К., Фаулер М.. Экстремальное программирование: планирование. Библиотека про-

граммиста. С.-Петербург: Питер. – 2003. – 144 с.

32. Бек К. Экстремальное программирование: разработка через тестирование. Библиотека

программиста. С.-Петербург: Питер. – 2003. – 224 с.

33. Ауэр К., Миллер Р. Экстремальное программирование: постановка процесса. С первых

шагов и до победного конца. Библиотека программиста. С.-Петербург: Питер, 2003. –

368 с.

34. Хаф Л. Методологии разработки программного обеспечения. Часть 2. Экстремальное

программирование // «Компьютер пресс».- №10.- 2003 (http://www.lib.csu.ru/dl/bases/

prg/kompress/articles/2003_10_XP/index.htm)

35. Парное программирование // www.osp.ru/cw/2001/09/044_0.htm

36. Коуберн А., Вильямс Л. Парное программирование: преимущества и недостатки //

www.maxkir.com/ sd/pairprog_RUS.htm

37. Страница “SCRUM” в энциклопедии “Wikipedia” // en.wikipedia.org/wiki/Scrum

38. Rising L., Janoff N. S. The Scrum Software Development Process for Small Teams // IEEE

Software. - july/aug 2000. - P. 26 – 32.

39. Highsmith J. Retiring Lifecycle Dinosaurs // Software Testing & Quality Engineering. -

May/June 2000 http://www.stqemagazine.com.