[TDD] Использование RUP для небольших проектов
Тестирование в свете Экстремального Программирования
Часть 2.
Использование RUP для небольших проектов: расширение экстремального программирования
http://www.cmcons.com/xp_testing_and_rup.htm
Гари Поллиц
Переведено БНТП
Аннотация
Данная статья посвящена достаточно интересному направлению в индустрии разработки и тестирования программного обеспечения, а именно экстремальному программированию. В статье представлены основные аспекты. Это первая часть серии статей по ХР и о том, как можно срастить ХР с методологии IBM Rational Unified Process
Статья переводная, и не все, о чем здесь говорится и как это говорится, нам нравится, но в целом данный подход имеет свое место.
В ближайшее время в нашей библиотеке появится 3 часть данного материала и большой материал о методологиях разработки (в том числе и XP).
Rational Unified Process (RUP) представляет собой целостную методологию организации процессов разработки программного обеспечения, которая включает в себя несколько заранее сформированных реферативных реализаций. Процессы, организуемые на основе RUP, варьируются от наиболее простых - предназначенных для небольших проектов с коротким циклом разработки - до более сложных процессов, покрывающих более широкий спектр потребностей больших, возможно даже распределенных, групп разработчиков. RUP успешно применяется в проектах любых типов и объемов. Данная статья описывает, как применять упрощенную версию RUP в небольших проектах. Мы описываем эффективные способы применения приемов экстремального программирования (XP - eXtreme Programming) в более широком контексте полного цикла проекта
Введение
Короткая история
Однажды утром ко мне подошел менеджер и спросил, не могу ли я потратить несколько недель на установку простой информационной системы для только что образованной венчурной компании. Мне было скучно заниматься моим текущим проектом и захотелось взяться за что-то новое, так что я ухватился за эту возможность - я мог работать быстро и создать замечательные новые решения, не обремененный бюрократическими процедурами, установленными в большой организации, в которой я работал.
Все начиналось просто замечательно. Первые 6 месяцев я работал в основном в одиночку - долгие, приятные часы. Моя продуктивность была просто невероятной, и я сделал одну из лучших работ за всю свою карьеру. Циклы разработки были короткими, и я обычно выпускал несколько важных новых частей системы каждые пару недель. Взаимодействие с пользователями было простым и непосредственным - мы все были участниками одной сплоченной команды и не обращали внимания на формальности и документы. Также мало формальностей было и в проектировании. Код был проектом, и проект был кодом. Все было отлично!
Все было отлично. Пока... По мере роста системы появлялись новые работы. Существующий код нужно было изменять в соответствии с новыми проблемами, и мы пересмотрели наши представления о том, что же нам действительно нужно делать. Я нанял несколько человек для помощи в разработке. Мы работали как единый организм, часто попарно занимаясь разными частями проблемы. Это упрощало взаимодействие, и мы могли отбросить формальности.
Прошел год
Мы продолжали нанимать сотрудников. Команда выросла сначала до трех, потом до пяти, а затем - до семи человек. Каждый раз при приеме нового человека возникал длительный период обучения, без предварительного опыта было трудно понять и объяснить систему в целом, даже на поверхностном уровне. Мы начали рисовать обзорные диаграммы, которые показывали общую структуру системы, ее основные концепции и интерфейсы более формально.
Мы продолжали использовать тестирование, как главный способ проверки того, что система делает именно то, что нужно. С увеличением количества новых людей на "пользовательской" стороне мы обнаружили, что неформальных требований и персональных контактов, которые срабатывали на ранних стадиях проекта, больше недостаточно. Теперь требовалось некоторое время, чтобы представить, что же мы должны разрабатывать. В результате мы стали сохранять записи обсуждений, чтобы не было необходимости постоянно возвращаться к уже принятым решениям. Мы также обнаружили, что описание требований и сценариев использования помогает обучать новых пользователей работе с системой.
Когда система выросла в объеме и усложнилась, случилось нечто неожиданное - оказалось, что архитектура системы требует пристального внимания. Вначале архитектура по преимуществу существовала в моей голове, позднее - в нескольких неразборчивых заметках или обрывочных схемах. Однако с увеличением количества участников проекта стало труднее сохранять контроль над архитектурой. Так как не все знали предысторию системы так же как я, они не могли видеть влияние отдельных конкретных изменений на архитектуру. Мы были вынуждены определить архитектурные ограничения системы в более строгих терминах. Любые изменения, которые могли повлиять на архитектуру, требовали группового консенсуса и, в конечном счете, моего одобрения. Мы обнаружили, что это тяжелый путь и нам пришлось пережить несколько болезненных ситуаций, прежде чем мы действительно осознали важность архитектуры.
Это реальная история. Она описывает лишь некоторые неприятные уроки этого проекта. Этот опыт отличается от общей практики только одним: некоторые из нас участвовали в этом от начала до конца в течение нескольких лет. Обычно люди приходят и уходят из проекта и не видят отдаленных результатов своих действий. Данному проекту могла помочь хотя бы небольшая формализация процесса. Слишком большая заорганизованность процессов засасывает, но отсутствие установленных процедур приводит к новым рискам. Также как человек, вкладывающий инвестиции в слишком рискованные акции ожидает только высоких дивидендов, группа, уделяющая слишком мало внимания процессам, игнорирует главные риски окружения своего проекта и "надеется на лучшее, но не готова к худшему".
Общие положения
Эта статья описывает, как применять процессы в проектах, подобных описанному выше. Мы сконцентрируем внимание на выборе "правильного уровня" процессов. Понимание проблем, с которыми сталкивается команда разработчиков, и бизнес окружения, в котором она работает, позволит нам выбрать правильный уровень формализации процессов. Как только мы поймем эти проблемы, мы сможем формализовать процессы ровно настолько, чтобы уменьшить риск. Не существует процессов, упрощенных или нет, одинаково подходящих для любых случаев. В следующих разделах мы рассмотрим идею о том, что правильный уровень процессов является функцией риска.
Мы посмотрим, как выбирать правильный уровень процессов, используя две популярные методологии: RUP (Rational Unified Process) фирмы Rational и XP (eXtreme Programming - экстремальное программирование). Мы покажем, как можно применять RUP в небольших проектах, и как это решает многие вопросы, не рассматриваемые в XP. Комбинация дает команде разработчиков методику, необходимую для устранения рисков и достижения своих целей по поставке программного продукта.
RUP - это схема процессов, разработанная в Rational Software. Это итеративная методология, основанная на шести признанных в отрасли лучших технологиях. Разворачиваясь во времени, проект на основе RUP проходит через четыре фазы:
фаза обследования (Inception);
фаза проработки проекта (Elaboration);
фаза построения системы (Construction);
фаза передачи в эксплуатацию (Transition).
Каждая фаза включает одну или несколько итераций. На каждой итерации вы прилагаете различные усилия для выполнения нескольких задач (или последовательностей работ), таких как определение требований, анализ и проектирование, тестирование и так далее. Основной целью RUP является сокращение рисков. Методология RUP уточнялась в ходе тысяч проектов, выполненных тысячами клиентов и партнеров компании Rational.
Типичная последовательность итераций
Для понимания того, как учет риска может влиять на формирование процесса, мы можем спросить себя, должны ли мы моделировать бизнес? Если существует сколько-нибудь значительный риск того, что отсутствие понимания бизнеса может привести к разработке неадекватной системы, мы, вероятно, должны потратить некоторые усилия на моделирование бизнеса. Должны ли мы придерживаться формальностей во время моделирования? Это зависит от нашей аудитории - если небольшая команда будет использовать результаты неформально, мы можем обойтись несколькими документами в свободной форме. Если другие сотрудники организации будут использовать эти результаты, или анализировать их, мы, возможно, должны приложить дополнительные усилия и уделить больше внимания корректности и понятности представления модели.
Вы можете адаптировать RUP для соответствия нуждам практически любого проекта. Если ни один из реферативных процессов или шаблонов не подходит к вашим конкретным требованиям, вы можете легко сформировать свою собственную схему. Схема описывает, как планировать проект на основе процессов, и таким образом представляет конкретную реализацию процессов для данного проекта. Это значит, что методология RUP может быть упрощена или усложнена по необходимости, что мы и проиллюстрируем в данной статье.
XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Это интеллектуальное детище Кента Бека и привлекло внимание программной индустрии в результате выполнения проекта С3 в Chrysler Corporation где-то в 1997 году. Также как и RUP, эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. XP предлагает несколько подходов, которые эффективны для соответствующих проектов и обстоятельств, но содержит неочевидные предположения, работы и роли.
RUP и XP исходят из различных философских основ. RUP - это система процессных компонент, методов и техник, которые вы можете применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP - более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP. Наш опыт показывает, что большинство программных проектов находится где-то посередине - в попытке достичь правильного уровня процессов для своей ситуации. Ни одна из границ спектра для них не является достаточной.
Когда вы объединяете универсальность RUP с некоторыми из техник XP, вы достигаете правильного соотношения процессов, что является привлекательным для всех членов команды проекта и служит предотвращению всех основных рисков проекта. Для команды небольшого проекта, работающей в окружении с относительно высоким уровнем доверия, где пользователь является участником команды, XP подходит чрезвычайно хорошо. По мере того, как команда становится более распределенной и объем кода возрастает, или при плохой проработке архитектуры, вам требуется что-то иное. Вам нужно нечто большее, чем XP, для проектов, в которых принят "контрактный" стиль взаимодействия с пользователем. RUP является базой, на которой вы можете построить XP с более надежным набором техник, чем обычно требуется для этого подхода.
Остальная часть этой статьи посвящена небольшим процессам, основанным на четырех фазах RUP. Для каждой из них мы определим задачи и производимые артефакты. Хотя RUP и XP выделяют различные роли и распределение обязанностей, мы не будем рассматривать здесь эти различия. Для любой организации или проекта, реальные участники проекта должны быть ассоциированы с соответствующими ролями в процессе.
Начало проекта - Inception
Фаза первоначального обследования (Inception) исключительно важна для новой разработки, так как здесь вы должны определить риски, связанные с бизнесом и требованиями, до начала выполнения проекта. Для проектов, касающихся развития существующей системы, фаза начального обследования будет более короткой, но на ней мы также концентрируем внимание на том, стоит ли проект делать, и выполним ли он.
Во время первоначального обследования вы формируете бизнес прецеденты для разработки программного обеспечения. Ключевым артефактом, производимым в результате первоначального обследования, является концепция системы (Vision). Это описание системы на верхнем уровне. Оно объясняет всем, что собой представляет система, а также может определять, кто и для чего будет ее использовать, какие возможности должны в ней присутствовать и какие существуют ограничения. Концепция системы может быть очень короткой, возможно всего один - два параграфа. Часто в концепции сформулированы критически важные возможности программы, которые должны быть предоставлены заказчику.
В следующем примере показано очень короткая концепция, созданная для проекта по реинжинирингу внешнего Web-сайта компании Rational.
Поддержание позиции Rational в качестве мирового лидера в автоматизации разработки (средства, услуги и передовые технологии) за счет упрочения связей с потребителями через динамическое, персонализированное Web-присутствие, обеспечивающее посетителю самообслуживание, поддержку и целевой контент. Новый процесс и обеспечивающие технологии дадут возможность поставщикам информации ускорить публикацию и качество контента за счет простого в использовании автоматизированного решения.
RUP специфицирует четыре важных задачи, решаемых на этапе начального обследования:
Формулировка рамок проекта. Если мы собираемся разрабатывать систему, мы должны знать, что она собой представляет, и как она будет удовлетворять требованиям заказчиков. При решении этой задачи мы определяем контекст и наиболее важные требования с достаточной степенью детализации для формирования критериев приемки продукта.
Планирование и подготовка бизнес прецедентов. Руководствуясь виденьем, мы определяем свою стратегию устранения риска, разрабатываем предварительный план проекта и определяем известные затраты, календарный план и прибыльность работ.
Синтез предварительной архитектуры. Если в рассматриваемой системе достаточно мало новшеств, и она имеет ясную архитектуру, вы можете пропустить этот шаг. Как только нам становятся известны требования заказчика, мы выделяем время на рассмотрение потенциально возможных архитектурных решений. Новые технологии приносят возможность новых и улучшенных решений для проблем программного обеспечения. Требуемое время на ранних стадиях проекта на сравнительный анализ затрат на приобретение или собственную разработку, так же как и на выбор технологий и, возможно, разработку первоначального прототипа, могут снизить некоторые из значительных рисков проекта.
Подготовка инфраструктуры проекта. Для любого проекта требуется инфраструктура. Используете ли вы некоторые из техник XP, такие как парное программирование, или более традиционные подходы, вам необходимо определить физические ресурсы, программные средства и процедуры, которым должна следовать команда разработчиков.
Выполнение первоначального обследования для небольших проектов не требует большого количества "формальных процессов". Часто вы можете завершить первоначальное обследование за пару дней или меньше. Следующие разделы описывают ожидаемые артефакты этой фазы, отличные от концепции системы.
Утвержденные бизнес прецеденты
Заинтересованные лица получают возможность согласиться, что с точки зрения бизнеса, проект имеет смысл выполнять. И RUP и XP сходятся в том, что лучше как можно раньше обнаружить, что проект выполнять не стоит, чем тратить ценные ресурсы на бессмысленный проект. XP, как это описано в Planning Extreme Programming, достаточно гибко относится к тому, как проект начинается и какие роли привлекаются (в контексте существующего бизнеса или системы это представляется очевидным), но в рамках своей фазы рассмотрения (Exploration) XP имеет дело с артефактами, эквивалентными получаемым на фазе начального обследования в RUP. Рассматриваете ли вы неформально вопросы предметной области в XP или формируете артефакты бизнес прецедентов первоклассного проекта в RUP, вам необходимо обратить на них внимание.
Список рисков
Вы ведете список рисков в течение всего проекта. Это может быть простой список рисков с планируемой стратегией их сокращения. Рискам присваиваются приоритеты. Все участники проекта могут видеть, что представляют собой риски, и как вы учитываете их в каждый конкретный момент. Кент Бек описывает набор рисков, которые снижаются с помощью XP и как обеспечивается их снижение, но не дает универсального подхода для борьбы с рисками.
Предварительный план проекта
В этот план включаются оценка ресурсов, функциональные границы и перечень этапов. В любом проекте эти оценки постоянно уточняются и вы должны отслеживать их изменения.
План приемки проекта
Нужен ли вам формальный план или нет, зависит от типа проекта. Вы должны решить, как заказчик будет определять успешность проекта. В проектах XP это определяется на основе приемочных тестов, создаваемых заказчиком. В более универсальных процессах, заказчик может не создавать реальных тестов, но критерии приемки должны исходить непосредственно от заказчика или от лица, такого как системный аналитик, которое непосредственно взаимодействует с заказчиком. Могут существовать и иные критерии приемки, такие как наличие документации пользователя и интерактивной справки. XP не рассматривает такие случаи.
План для начальной итерации проработки проекта (Elaboration)
В проектах RUP вы детально планируете каждую итерацию в конце предыдущей итерации. В конце итерации вы оцениваете прогресс в соответствие с критериями, выбранными на начальном этапе итерации. XP предлагает некоторые удачные решения для мониторинга и измерения успешности итерации. Метрики достаточно просты и вы можете легко включить их в план итерации и критерии оценки.
Исходная модель прецедентов
Несмотря на кажущееся излишним усложнением и формализмом, это достаточно просто. Набор прецедентов соответствует "историям", записываемым заказчиком в XP. Различие заключается в том, что модель прецедентов содержит полный набор действий, инициируемых актером (кем-то или чем-то внешним по отношению к системе), которые имеют очевидную значимость. Прецедент может включать несколько историй XP. Для определения функциональных границ проекта RUP рекомендует идентифицировать прецеденты и актеров во время начального обследования. Концентрация внимания на полном, с точки зрения пользователя, наборе действий помогает произвести декомпозицию системы на части, имеющие самостоятельное значение. Это, в свою очередь, дает возможность спланировать реализацию функциональности таким образом, чтобы передавать пользователю что-то в конце каждой итерации (возможно за исключением только итераций начального обследования и проработки проекта).
Как RUP, так и XP, помогают нам удостовериться, что мы не окажемся в ситуации, когда готово около 80% системы, но при этом нет ничего завершенного для передачи пользователю. Мы всегда предпочитаем иметь возможность разрабатывать системы, приносящие какую-либо пользу заказчику.
Модель прецедентов в этот момент идентифицирует прецеденты использования и актеров с минимальной детализацией или вообще без нее. Это может быть простой текст или диаграммы UML (Unified Modeling Language - универсальный язык моделирования), нарисованные от руки или с помощью графического редактора. Такая модель помогает нам убедиться, что мы включили необходимые заинтересованным лицам функции, ничего не забыв, и позволяет легко представить систему в целом. Для прецедентов назначаются приоритеты на основе таких факторов как риск, важность для заказчика и техническая сложность. Ни один из артефактов начального обследования не должен быть излишне формальным или объемным. Делайте их настолько простыми и строгими, насколько это вам необходимо. XP включает советы по планированию приемки системы. RUP привносит кое-что еще на ранних стадиях проекта. Эти небольшие дополнения могут примести существенные дивиденды при учете более полного набора рисков.
Проработка проекта - Elaboration
Целью фазы проработки проекта является закладка основ архитектуры системы, обеспечивающих устойчивый фундамент для основных работ по проектированию и реализации, осуществляемых на стадии построения системы (Construction). Архитектура происходит из рассмотрения наиболее значимых требований (тех, которые оказывают наибольшее значение на архитектуру системы) и оценки рисков. Устойчивость архитектуры оценивается с помощью одного или нескольких прототипов архитектуры.
В RUP процесс проектирования концентрируется вокруг определения архитектуры системы и для систем с большой долей программного обеспечения - вокруг архитектуры программного обеспечения. Использование компонентных архитектур - один из шести наилучших подходов к разработке программ, инкорпорированных в RUP, рекомендует уделять больше времени на разработку и сопровождение архитектур. Время, затраченное на эти усилия, сокращает риски, связанные с ненадежными и негибкими системами.
XP замещает представление архитектуры "метафорой". Метафора отражает часть архитектуры, тогда как оставшиеся части являются естественным результатом разработки кода. В XP предполагается, что архитектура появляется в результате простейшего проектирования и постоянного реформирования (refactoring) кода.
В RUP архитектура более чем метафора. Во время проработки проекта вы конструируете выполняемые архитектуры, с помощью которых возможно устранение многих рисков, связанных с нефункциональными требованиями, такими как производительность, надежность и устойчивость. Читая литературу по XP, можно прийти к заключению: то, что RUP предписывает для фазы проработки проекты, особенно несвоевременная концентрация на том, что в XP называется инфраструктурой - попусту растраченное время. В XP утверждается, что излишние затраты на построение инфраструктуры ведут к избыточно сложным решениям и разработке вещей, которые не приносят никакой пользы заказчику. В RUP архитектура и инфраструктура - разные вещи.
Подходы к архитектуре в RUP и XP несколько отличаются. RUP советует вам уделять внимание архитектуре во избежание рисков, связанных с превышением времени на разработку, излишним объемом проекта и введением новых технологий. В XP предполагается либо наличие архитектуры, либо что архитектура настолько проста и понятна, что может быть выведена непосредственно из кода. XP советует не проектировать на будущее, а реализовывать то, что нужно сегодня. Предполагается, что будущее сможет позаботиться о себе само, если вы будете сохранять проект настолько простым, насколько это возможно. RUP приглашает вас оценить риски такого предположения. Если даже система или ее часть будут переписываться в будущем, XP отмечает, что это все равно лучше, и зачастую дешевле, чем планировать такую возможность изначально. Для некоторых систем это действительно так, и при использовании RUP рассмотрение риска во время проработки проекта может привести вас к такому выводу. RUP не считает это истинным для всех систем и, как показывает опыт больших, более сложных систем, этот фактор может оказаться катастрофическим.
Наряду с тем, что излишнее внимание к будущим возможностям, которые могут никогда и не возникнуть, действительно бесполезно, мы верим, что достаточное внимание к будущему - вещь предусмотрительная. Сколько компаний могут позволить себе постоянно переписывать или даже переформировывать код?
В любом проекте во время проработки проекта вы должны решить, как минимум, три задачи:
Определить, проверить и обосновать архитектуру. Используйте список рисков для разработки возможных архитектур, полученных на фазе первоначального обследования. Мы заинтересованы в том, чтобы проектируемое программное обеспечение было реализуемо. Если выбранная технология достаточно известна или система не очень сложна, этот этап не займет много времени. Если вы расширяете существующую систему, этот этап может вообще не потребоваться, если существующая архитектура не требует изменений. Когда присутствует реальный риск, связанный с архитектурой, вы не захотите оставить архитектуру на волю случая. Как часть решения этой задачи вы можете осуществить выбор некоторых компонент для принятия решений относительно их покупки, разработки или повторного использования. Если затраты будут велики, вы можете разбить их на несколько составляющих работ.
Уточнение Концепции системы. Во время фазы начального обследования вы разработали концепцию. После того как вы определили реализуемость проекта, и владельцы требований получили возможность просмотреть и прокомментировать систему, могут возникнуть изменения в документе, описывающем концепцию системы, и в требованиях. Пересмотр концепции и требований обычно выполняется во время проработки проекта. К концу проработки проекта у вас появится ясное понимание наиболее важных прецедентов, которые влияют на архитектурные и плановые решения. Заинтересованные лица должны согласиться с тем, что текущая версия концепции системы будет реализована, если вы выполните текущий план разработки полной системы в контексте текущей архитектуры. Количество изменений должно уменьшиться на последующих итерациях, но вы должны предусмотреть выделение некоторого времени на управление требованиями на каждой из итераций.
Создание и обоснование планов итераций для фазы построения системы (Construction). Теперь детализируйте ваш план. В конце каждой итерации вы возвращаетесь к плану и модифицируете его по необходимости. Модификации обычно случаются из-за неправильной оценки затрат, изменения бизнес окружения или изменения требований. Назначьте приоритеты для прецедентов, сценариев и технических затрат, а затем распределите их по итерациям. В конце каждой итерации вы планируете иметь рабочий продукт, имеющий значение для ваших владельцев требований.
Вы можете выполнять и другие работы в ходе проработки проекта. Мы рекомендуем сформировать среду тестирования и начать разрабатывать тесты. До того, как появится детальный код, вы можете начать разрабатывать и, возможно, реализовывать интеграционные тесты. Программисты должны быть готовы разрабатывать компонентные тесты и знать, как использовать средства тестирования, выбранные для проекта. XP рекомендует разрабатывать тесты до начала кодирования. Это хорошая идея, особенно когда вы дополняете существующий код. Как бы вы не решили осуществлять тестирование, моментом для установления регламента тестирования является проработка проекта.
Фаза проработки проекта в версии RUP охватывает элементы фаз исследования (Exploration) и утверждения (Commitment) по версии XP. Подход XP к техническим рискам, таким как новизна и сложность, - это "импульсное" решение. Выделите какое-то время на эксперименты для оценки затрат. Этот прием помогает во многих случаях. Когда существует больший риск, не покрывающийся одним прецедентом или историей, вам необходимо приложить больше усилий, чтобы убедиться в успехе системы и точной оценке затрат.
Обычно во время проработки проекта вы обновляете артефакты, полученные в ходе начального обследования, такие как требования и список рисков. Артефакты, которые могут появиться во время проработки проекта:
Описание архитектуры программного обеспечения SAD (Software Architecture Document) SAD - это составной артефакт, который обеспечивает единый источник для всей технической информации о проекте. В конце проработки проекта он может содержать детальное описание архитектурно значимых прецедентов и определение ключевых механизмов и проектных элементов. Когда проект расширяет существующую систему, вы можете использовать предыдущий SAD или вы можете решить, что отсутствие такого документа не составляет существенного риска. В любом случае, перед созданием документа вам следует все обдумать.
Планы итераций для построения системы (Construction). Во время проработки проекта вы планируете число итераций фазы построения системы. Каждая итерация включает конкретные прецеденты, сценарии и другие рабочие материалы, назначенные ей. Эта информация отражается и утверждается в планах итераций. Просмотр и утверждение планов является критерием завершения проработки проекта. В очень маленьких, коротких проектах вы можете объединить фазу проработки проекта с начальным обследованием и построением системы. Основные работы при этом выполняются, но ресурсы на планирование и анализ итераций сокращаются.
Тестирование в свете Экстремального Программирования
Часть 2.
Использование RUP для небольших проектов: расширение экстремального программирования
http://www.cmcons.com/xp_testing_and_rup.htm
Гари Поллиц
Переведено БНТП
Аннотация
Данная статья посвящена достаточно интересному направлению в индустрии разработки и тестирования программного обеспечения, а именно экстремальному программированию. В статье представлены основные аспекты. Это первая часть серии статей по ХР и о том, как можно срастить ХР с методологии IBM Rational Unified Process
Статья переводная, и не все, о чем здесь говорится и как это говорится, нам нравится, но в целом данный подход имеет свое место.
В ближайшее время в нашей библиотеке появится 3 часть данного материала и большой материал о методологиях разработки (в том числе и XP).
Rational Unified Process (RUP) представляет собой целостную методологию организации процессов разработки программного обеспечения, которая включает в себя несколько заранее сформированных реферативных реализаций. Процессы, организуемые на основе RUP, варьируются от наиболее простых - предназначенных для небольших проектов с коротким циклом разработки - до более сложных процессов, покрывающих более широкий спектр потребностей больших, возможно даже распределенных, групп разработчиков. RUP успешно применяется в проектах любых типов и объемов. Данная статья описывает, как применять упрощенную версию RUP в небольших проектах. Мы описываем эффективные способы применения приемов экстремального программирования (XP - eXtreme Programming) в более широком контексте полного цикла проекта
Введение
Короткая история
Однажды утром ко мне подошел менеджер и спросил, не могу ли я потратить несколько недель на установку простой информационной системы для только что образованной венчурной компании. Мне было скучно заниматься моим текущим проектом и захотелось взяться за что-то новое, так что я ухватился за эту возможность - я мог работать быстро и создать замечательные новые решения, не обремененный бюрократическими процедурами, установленными в большой организации, в которой я работал.
Все начиналось просто замечательно. Первые 6 месяцев я работал в основном в одиночку - долгие, приятные часы. Моя продуктивность была просто невероятной, и я сделал одну из лучших работ за всю свою карьеру. Циклы разработки были короткими, и я обычно выпускал несколько важных новых частей системы каждые пару недель. Взаимодействие с пользователями было простым и непосредственным - мы все были участниками одной сплоченной команды и не обращали внимания на формальности и документы. Также мало формальностей было и в проектировании. Код был проектом, и проект был кодом. Все было отлично!
Все было отлично. Пока... По мере роста системы появлялись новые работы. Существующий код нужно было изменять в соответствии с новыми проблемами, и мы пересмотрели наши представления о том, что же нам действительно нужно делать. Я нанял несколько человек для помощи в разработке. Мы работали как единый организм, часто попарно занимаясь разными частями проблемы. Это упрощало взаимодействие, и мы могли отбросить формальности.
Прошел год
Мы продолжали нанимать сотрудников. Команда выросла сначала до трех, потом до пяти, а затем - до семи человек. Каждый раз при приеме нового человека возникал длительный период обучения, без предварительного опыта было трудно понять и объяснить систему в целом, даже на поверхностном уровне. Мы начали рисовать обзорные диаграммы, которые показывали общую структуру системы, ее основные концепции и интерфейсы более формально.
Мы продолжали использовать тестирование, как главный способ проверки того, что система делает именно то, что нужно. С увеличением количества новых людей на "пользовательской" стороне мы обнаружили, что неформальных требований и персональных контактов, которые срабатывали на ранних стадиях проекта, больше недостаточно. Теперь требовалось некоторое время, чтобы представить, что же мы должны разрабатывать. В результате мы стали сохранять записи обсуждений, чтобы не было необходимости постоянно возвращаться к уже принятым решениям. Мы также обнаружили, что описание требований и сценариев использования помогает обучать новых пользователей работе с системой.
Когда система выросла в объеме и усложнилась, случилось нечто неожиданное - оказалось, что архитектура системы требует пристального внимания. Вначале архитектура по преимуществу существовала в моей голове, позднее - в нескольких неразборчивых заметках или обрывочных схемах. Однако с увеличением количества участников проекта стало труднее сохранять контроль над архитектурой. Так как не все знали предысторию системы так же как я, они не могли видеть влияние отдельных конкретных изменений на архитектуру. Мы были вынуждены определить архитектурные ограничения системы в более строгих терминах. Любые изменения, которые могли повлиять на архитектуру, требовали группового консенсуса и, в конечном счете, моего одобрения. Мы обнаружили, что это тяжелый путь и нам пришлось пережить несколько болезненных ситуаций, прежде чем мы действительно осознали важность архитектуры.
Это реальная история. Она описывает лишь некоторые неприятные уроки этого проекта. Этот опыт отличается от общей практики только одним: некоторые из нас участвовали в этом от начала до конца в течение нескольких лет. Обычно люди приходят и уходят из проекта и не видят отдаленных результатов своих действий. Данному проекту могла помочь хотя бы небольшая формализация процесса. Слишком большая заорганизованность процессов засасывает, но отсутствие установленных процедур приводит к новым рискам. Также как человек, вкладывающий инвестиции в слишком рискованные акции ожидает только высоких дивидендов, группа, уделяющая слишком мало внимания процессам, игнорирует главные риски окружения своего проекта и "надеется на лучшее, но не готова к худшему".
Общие положения
Эта статья описывает, как применять процессы в проектах, подобных описанному выше. Мы сконцентрируем внимание на выборе "правильного уровня" процессов. Понимание проблем, с которыми сталкивается команда разработчиков, и бизнес окружения, в котором она работает, позволит нам выбрать правильный уровень формализации процессов. Как только мы поймем эти проблемы, мы сможем формализовать процессы ровно настолько, чтобы уменьшить риск. Не существует процессов, упрощенных или нет, одинаково подходящих для любых случаев. В следующих разделах мы рассмотрим идею о том, что правильный уровень процессов является функцией риска.
Мы посмотрим, как выбирать правильный уровень процессов, используя две популярные методологии: RUP (Rational Unified Process) фирмы Rational и XP (eXtreme Programming - экстремальное программирование). Мы покажем, как можно применять RUP в небольших проектах, и как это решает многие вопросы, не рассматриваемые в XP. Комбинация дает команде разработчиков методику, необходимую для устранения рисков и достижения своих целей по поставке программного продукта.
RUP - это схема процессов, разработанная в Rational Software. Это итеративная методология, основанная на шести признанных в отрасли лучших технологиях. Разворачиваясь во времени, проект на основе RUP проходит через четыре фазы:
фаза обследования (Inception);
фаза проработки проекта (Elaboration);
фаза построения системы (Construction);
фаза передачи в эксплуатацию (Transition).
Каждая фаза включает одну или несколько итераций. На каждой итерации вы прилагаете различные усилия для выполнения нескольких задач (или последовательностей работ), таких как определение требований, анализ и проектирование, тестирование и так далее. Основной целью RUP является сокращение рисков. Методология RUP уточнялась в ходе тысяч проектов, выполненных тысячами клиентов и партнеров компании Rational.
Типичная последовательность итераций
Для понимания того, как учет риска может влиять на формирование процесса, мы можем спросить себя, должны ли мы моделировать бизнес? Если существует сколько-нибудь значительный риск того, что отсутствие понимания бизнеса может привести к разработке неадекватной системы, мы, вероятно, должны потратить некоторые усилия на моделирование бизнеса. Должны ли мы придерживаться формальностей во время моделирования? Это зависит от нашей аудитории - если небольшая команда будет использовать результаты неформально, мы можем обойтись несколькими документами в свободной форме. Если другие сотрудники организации будут использовать эти результаты, или анализировать их, мы, возможно, должны приложить дополнительные усилия и уделить больше внимания корректности и понятности представления модели.
Вы можете адаптировать RUP для соответствия нуждам практически любого проекта. Если ни один из реферативных процессов или шаблонов не подходит к вашим конкретным требованиям, вы можете легко сформировать свою собственную схему. Схема описывает, как планировать проект на основе процессов, и таким образом представляет конкретную реализацию процессов для данного проекта. Это значит, что методология RUP может быть упрощена или усложнена по необходимости, что мы и проиллюстрируем в данной статье.
XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Это интеллектуальное детище Кента Бека и привлекло внимание программной индустрии в результате выполнения проекта С3 в Chrysler Corporation где-то в 1997 году. Также как и RUP, эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. XP предлагает несколько подходов, которые эффективны для соответствующих проектов и обстоятельств, но содержит неочевидные предположения, работы и роли.
RUP и XP исходят из различных философских основ. RUP - это система процессных компонент, методов и техник, которые вы можете применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP - более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP. Наш опыт показывает, что большинство программных проектов находится где-то посередине - в попытке достичь правильного уровня процессов для своей ситуации. Ни одна из границ спектра для них не является достаточной.
Когда вы объединяете универсальность RUP с некоторыми из техник XP, вы достигаете правильного соотношения процессов, что является привлекательным для всех членов команды проекта и служит предотвращению всех основных рисков проекта. Для команды небольшого проекта, работающей в окружении с относительно высоким уровнем доверия, где пользователь является участником команды, XP подходит чрезвычайно хорошо. По мере того, как команда становится более распределенной и объем кода возрастает, или при плохой проработке архитектуры, вам требуется что-то иное. Вам нужно нечто большее, чем XP, для проектов, в которых принят "контрактный" стиль взаимодействия с пользователем. RUP является базой, на которой вы можете построить XP с более надежным набором техник, чем обычно требуется для этого подхода.
Остальная часть этой статьи посвящена небольшим процессам, основанным на четырех фазах RUP. Для каждой из них мы определим задачи и производимые артефакты. Хотя RUP и XP выделяют различные роли и распределение обязанностей, мы не будем рассматривать здесь эти различия. Для любой организации или проекта, реальные участники проекта должны быть ассоциированы с соответствующими ролями в процессе.
Начало проекта - Inception
Фаза первоначального обследования (Inception) исключительно важна для новой разработки, так как здесь вы должны определить риски, связанные с бизнесом и требованиями, до начала выполнения проекта. Для проектов, касающихся развития существующей системы, фаза начального обследования будет более короткой, но на ней мы также концентрируем внимание на том, стоит ли проект делать, и выполним ли он.
Во время первоначального обследования вы формируете бизнес прецеденты для разработки программного обеспечения. Ключевым артефактом, производимым в результате первоначального обследования, является концепция системы (Vision). Это описание системы на верхнем уровне. Оно объясняет всем, что собой представляет система, а также может определять, кто и для чего будет ее использовать, какие возможности должны в ней присутствовать и какие существуют ограничения. Концепция системы может быть очень короткой, возможно всего один - два параграфа. Часто в концепции сформулированы критически важные возможности программы, которые должны быть предоставлены заказчику.
В следующем примере показано очень короткая концепция, созданная для проекта по реинжинирингу внешнего Web-сайта компании Rational.
Поддержание позиции Rational в качестве мирового лидера в автоматизации разработки (средства, услуги и передовые технологии) за счет упрочения связей с потребителями через динамическое, персонализированное Web-присутствие, обеспечивающее посетителю самообслуживание, поддержку и целевой контент. Новый процесс и обеспечивающие технологии дадут возможность поставщикам информации ускорить публикацию и качество контента за счет простого в использовании автоматизированного решения.
RUP специфицирует четыре важных задачи, решаемых на этапе начального обследования:
Формулировка рамок проекта. Если мы собираемся разрабатывать систему, мы должны знать, что она собой представляет, и как она будет удовлетворять требованиям заказчиков. При решении этой задачи мы определяем контекст и наиболее важные требования с достаточной степенью детализации для формирования критериев приемки продукта.
Планирование и подготовка бизнес прецедентов. Руководствуясь виденьем, мы определяем свою стратегию устранения риска, разрабатываем предварительный план проекта и определяем известные затраты, календарный план и прибыльность работ.
Синтез предварительной архитектуры. Если в рассматриваемой системе достаточно мало новшеств, и она имеет ясную архитектуру, вы можете пропустить этот шаг. Как только нам становятся известны требования заказчика, мы выделяем время на рассмотрение потенциально возможных архитектурных решений. Новые технологии приносят возможность новых и улучшенных решений для проблем программного обеспечения. Требуемое время на ранних стадиях проекта на сравнительный анализ затрат на приобретение или собственную разработку, так же как и на выбор технологий и, возможно, разработку первоначального прототипа, могут снизить некоторые из значительных рисков проекта.
Подготовка инфраструктуры проекта. Для любого проекта требуется инфраструктура. Используете ли вы некоторые из техник XP, такие как парное программирование, или более традиционные подходы, вам необходимо определить физические ресурсы, программные средства и процедуры, которым должна следовать команда разработчиков.
Выполнение первоначального обследования для небольших проектов не требует большого количества "формальных процессов". Часто вы можете завершить первоначальное обследование за пару дней или меньше. Следующие разделы описывают ожидаемые артефакты этой фазы, отличные от концепции системы.
Утвержденные бизнес прецеденты
Заинтересованные лица получают возможность согласиться, что с точки зрения бизнеса, проект имеет смысл выполнять. И RUP и XP сходятся в том, что лучше как можно раньше обнаружить, что проект выполнять не стоит, чем тратить ценные ресурсы на бессмысленный проект. XP, как это описано в Planning Extreme Programming, достаточно гибко относится к тому, как проект начинается и какие роли привлекаются (в контексте существующего бизнеса или системы это представляется очевидным), но в рамках своей фазы рассмотрения (Exploration) XP имеет дело с артефактами, эквивалентными получаемым на фазе начального обследования в RUP. Рассматриваете ли вы неформально вопросы предметной области в XP или формируете артефакты бизнес прецедентов первоклассного проекта в RUP, вам необходимо обратить на них внимание.
Список рисков
Вы ведете список рисков в течение всего проекта. Это может быть простой список рисков с планируемой стратегией их сокращения. Рискам присваиваются приоритеты. Все участники проекта могут видеть, что представляют собой риски, и как вы учитываете их в каждый конкретный момент. Кент Бек описывает набор рисков, которые снижаются с помощью XP и как обеспечивается их снижение, но не дает универсального подхода для борьбы с рисками.
Предварительный план проекта
В этот план включаются оценка ресурсов, функциональные границы и перечень этапов. В любом проекте эти оценки постоянно уточняются и вы должны отслеживать их изменения.
План приемки проекта
Нужен ли вам формальный план или нет, зависит от типа проекта. Вы должны решить, как заказчик будет определять успешность проекта. В проектах XP это определяется на основе приемочных тестов, создаваемых заказчиком. В более универсальных процессах, заказчик может не создавать реальных тестов, но критерии приемки должны исходить непосредственно от заказчика или от лица, такого как системный аналитик, которое непосредственно взаимодействует с заказчиком. Могут существовать и иные критерии приемки, такие как наличие документации пользователя и интерактивной справки. XP не рассматривает такие случаи.
План для начальной итерации проработки проекта (Elaboration)
В проектах RUP вы детально планируете каждую итерацию в конце предыдущей итерации. В конце итерации вы оцениваете прогресс в соответствие с критериями, выбранными на начальном этапе итерации. XP предлагает некоторые удачные решения для мониторинга и измерения успешности итерации. Метрики достаточно просты и вы можете легко включить их в план итерации и критерии оценки.
Исходная модель прецедентов
Несмотря на кажущееся излишним усложнением и формализмом, это достаточно просто. Набор прецедентов соответствует "историям", записываемым заказчиком в XP. Различие заключается в том, что модель прецедентов содержит полный набор действий, инициируемых актером (кем-то или чем-то внешним по отношению к системе), которые имеют очевидную значимость. Прецедент может включать несколько историй XP. Для определения функциональных границ проекта RUP рекомендует идентифицировать прецеденты и актеров во время начального обследования. Концентрация внимания на полном, с точки зрения пользователя, наборе действий помогает произвести декомпозицию системы на части, имеющие самостоятельное значение. Это, в свою очередь, дает возможность спланировать реализацию функциональности таким образом, чтобы передавать пользователю что-то в конце каждой итерации (возможно за исключением только итераций начального обследования и проработки проекта).
Как RUP, так и XP, помогают нам удостовериться, что мы не окажемся в ситуации, когда готово около 80% системы, но при этом нет ничего завершенного для передачи пользователю. Мы всегда предпочитаем иметь возможность разрабатывать системы, приносящие какую-либо пользу заказчику.
Модель прецедентов в этот момент идентифицирует прецеденты использования и актеров с минимальной детализацией или вообще без нее. Это может быть простой текст или диаграммы UML (Unified Modeling Language - универсальный язык моделирования), нарисованные от руки или с помощью графического редактора. Такая модель помогает нам убедиться, что мы включили необходимые заинтересованным лицам функции, ничего не забыв, и позволяет легко представить систему в целом. Для прецедентов назначаются приоритеты на основе таких факторов как риск, важность для заказчика и техническая сложность. Ни один из артефактов начального обследования не должен быть излишне формальным или объемным. Делайте их настолько простыми и строгими, насколько это вам необходимо. XP включает советы по планированию приемки системы. RUP привносит кое-что еще на ранних стадиях проекта. Эти небольшие дополнения могут примести существенные дивиденды при учете более полного набора рисков.
Проработка проекта - Elaboration
Целью фазы проработки проекта является закладка основ архитектуры системы, обеспечивающих устойчивый фундамент для основных работ по проектированию и реализации, осуществляемых на стадии построения системы (Construction). Архитектура происходит из рассмотрения наиболее значимых требований (тех, которые оказывают наибольшее значение на архитектуру системы) и оценки рисков. Устойчивость архитектуры оценивается с помощью одного или нескольких прототипов архитектуры.
В RUP процесс проектирования концентрируется вокруг определения архитектуры системы и для систем с большой долей программного обеспечения - вокруг архитектуры программного обеспечения. Использование компонентных архитектур - один из шести наилучших подходов к разработке программ, инкорпорированных в RUP, рекомендует уделять больше времени на разработку и сопровождение архитектур. Время, затраченное на эти усилия, сокращает риски, связанные с ненадежными и негибкими системами.
XP замещает представление архитектуры "метафорой". Метафора отражает часть архитектуры, тогда как оставшиеся части являются естественным результатом разработки кода. В XP предполагается, что архитектура появляется в результате простейшего проектирования и постоянного реформирования (refactoring) кода.
В RUP архитектура более чем метафора. Во время проработки проекта вы конструируете выполняемые архитектуры, с помощью которых возможно устранение многих рисков, связанных с нефункциональными требованиями, такими как производительность, надежность и устойчивость. Читая литературу по XP, можно прийти к заключению: то, что RUP предписывает для фазы проработки проекты, особенно несвоевременная концентрация на том, что в XP называется инфраструктурой - попусту растраченное время. В XP утверждается, что излишние затраты на построение инфраструктуры ведут к избыточно сложным решениям и разработке вещей, которые не приносят никакой пользы заказчику. В RUP архитектура и инфраструктура - разные вещи.
Подходы к архитектуре в RUP и XP несколько отличаются. RUP советует вам уделять внимание архитектуре во избежание рисков, связанных с превышением времени на разработку, излишним объемом проекта и введением новых технологий. В XP предполагается либо наличие архитектуры, либо что архитектура настолько проста и понятна, что может быть выведена непосредственно из кода. XP советует не проектировать на будущее, а реализовывать то, что нужно сегодня. Предполагается, что будущее сможет позаботиться о себе само, если вы будете сохранять проект настолько простым, насколько это возможно. RUP приглашает вас оценить риски такого предположения. Если даже система или ее часть будут переписываться в будущем, XP отмечает, что это все равно лучше, и зачастую дешевле, чем планировать такую возможность изначально. Для некоторых систем это действительно так, и при использовании RUP рассмотрение риска во время проработки проекта может привести вас к такому выводу. RUP не считает это истинным для всех систем и, как показывает опыт больших, более сложных систем, этот фактор может оказаться катастрофическим.
Наряду с тем, что излишнее внимание к будущим возможностям, которые могут никогда и не возникнуть, действительно бесполезно, мы верим, что достаточное внимание к будущему - вещь предусмотрительная. Сколько компаний могут позволить себе постоянно переписывать или даже переформировывать код?
В любом проекте во время проработки проекта вы должны решить, как минимум, три задачи:
Определить, проверить и обосновать архитектуру. Используйте список рисков для разработки возможных архитектур, полученных на фазе первоначального обследования. Мы заинтересованы в том, чтобы проектируемое программное обеспечение было реализуемо. Если выбранная технология достаточно известна или система не очень сложна, этот этап не займет много времени. Если вы расширяете существующую систему, этот этап может вообще не потребоваться, если существующая архитектура не требует изменений. Когда присутствует реальный риск, связанный с архитектурой, вы не захотите оставить архитектуру на волю случая. Как часть решения этой задачи вы можете осуществить выбор некоторых компонент для принятия решений относительно их покупки, разработки или повторного использования. Если затраты будут велики, вы можете разбить их на несколько составляющих работ.
Уточнение Концепции системы. Во время фазы начального обследования вы разработали концепцию. После того как вы определили реализуемость проекта, и владельцы требований получили возможность просмотреть и прокомментировать систему, могут возникнуть изменения в документе, описывающем концепцию системы, и в требованиях. Пересмотр концепции и требований обычно выполняется во время проработки проекта. К концу проработки проекта у вас появится ясное понимание наиболее важных прецедентов, которые влияют на архитектурные и плановые решения. Заинтересованные лица должны согласиться с тем, что текущая версия концепции системы будет реализована, если вы выполните текущий план разработки полной системы в контексте текущей архитектуры. Количество изменений должно уменьшиться на последующих итерациях, но вы должны предусмотреть выделение некоторого времени на управление требованиями на каждой из итераций.
Создание и обоснование планов итераций для фазы построения системы (Construction). Теперь детализируйте ваш план. В конце каждой итерации вы возвращаетесь к плану и модифицируете его по необходимости. Модификации обычно случаются из-за неправильной оценки затрат, изменения бизнес окружения или изменения требований. Назначьте приоритеты для прецедентов, сценариев и технических затрат, а затем распределите их по итерациям. В конце каждой итерации вы планируете иметь рабочий продукт, имеющий значение для ваших владельцев требований.
Вы можете выполнять и другие работы в ходе проработки проекта. Мы рекомендуем сформировать среду тестирования и начать разрабатывать тесты. До того, как появится детальный код, вы можете начать разрабатывать и, возможно, реализовывать интеграционные тесты. Программисты должны быть готовы разрабатывать компонентные тесты и знать, как использовать средства тестирования, выбранные для проекта. XP рекомендует разрабатывать тесты до начала кодирования. Это хорошая идея, особенно когда вы дополняете существующий код. Как бы вы не решили осуществлять тестирование, моментом для установления регламента тестирования является проработка проекта.
Фаза проработки проекта в версии RUP охватывает элементы фаз исследования (Exploration) и утверждения (Commitment) по версии XP. Подход XP к техническим рискам, таким как новизна и сложность, - это "импульсное" решение. Выделите какое-то время на эксперименты для оценки затрат. Этот прием помогает во многих случаях. Когда существует больший риск, не покрывающийся одним прецедентом или историей, вам необходимо приложить больше усилий, чтобы убедиться в успехе системы и точной оценке затрат.
Обычно во время проработки проекта вы обновляете артефакты, полученные в ходе начального обследования, такие как требования и список рисков. Артефакты, которые могут появиться во время проработки проекта:
Описание архитектуры программного обеспечения SAD (Software Architecture Document) SAD - это составной артефакт, который обеспечивает единый источник для всей технической информации о проекте. В конце проработки проекта он может содержать детальное описание архитектурно значимых прецедентов и определение ключевых механизмов и проектных элементов. Когда проект расширяет существующую систему, вы можете использовать предыдущий SAD или вы можете решить, что отсутствие такого документа не составляет существенного риска. В любом случае, перед созданием документа вам следует все обдумать.
Планы итераций для построения системы (Construction). Во время проработки проекта вы планируете число итераций фазы построения системы. Каждая итерация включает конкретные прецеденты, сценарии и другие рабочие материалы, назначенные ей. Эта информация отражается и утверждается в планах итераций. Просмотр и утверждение планов является критерием завершения проработки проекта. В очень маленьких, коротких проектах вы можете объединить фазу проработки проекта с начальным обследованием и построением системы. Основные работы при этом выполняются, но ресурсы на планирование и анализ итераций сокращаются.