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

Я не являюсь приверженцем или фанатиком методологий Agile (XP, Lean, Scrum, FDD и др.) - равно как любой другой. Почему? Потому что, при agile-подходе часто пренебрегают созданием «дорожной карты» развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта».

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

Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации. Кроме того, считается, что работа в agile-команде мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход - «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов. А это уже диагноз.

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

Каскадная модель - (waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

В 1970 году в своей статье У.У. Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель» (в простонародье - "водопад"), и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели. В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:

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

2. Проектирование

3. Конструирование (также «реализация» либо «кодирование»)

4. Интеграция

5. Тестирование и отладка (также «верификация»)

6. Инсталляция

7. Поддержка

Жизненный цикл каскадной модели.

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

Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.

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

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

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

Критика каскадной модели и гибридные методологические решения.

Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным. Поэтому даже в PMBOK (Project Management Body of Knowledge) 3-ей версии формально была закреплена только методика «каскадной модели» и не были предложены альтернативные варианты, известные как итеративное ведение проектов. Начиная с PMBOK 4-ой версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года, формально Институтом Проектного Менеджмента (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «водопада», так и достижения итеративных методологов.

Модель водопада является разумным выбором для типовых, стандартных проектов или при наличии жестких требований к качеству (например, при создании mission critical-систем). Тем не менее, ее недостатки весьма существенны, и для разработки коммерческого ПО, как правило, существуют значительно более эффективные альтернативы.

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

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

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

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

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

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

5. Основные проектные риски могут (и должны) быть разрешены на первых итерациях. Например, архитектурное решение, приводящее к неприемлемой производительности может быть обнаружено и исправлено уже в первой итерации.

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

DSDM (Dynamic Systems Development Method) - метод разработки динамических систем, основанный, главным образом, на концепции быстрой разработки приложений (Rapid Application Development, RAD). В 2007 году DSDM стал основным подходом к управлению проектом и разработки приложений. DSDM - это итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.

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

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

• Трёх стадий: предпроектная, стадия жизненного цикла проекта и постпроектная стадия.

• Стадия жизни проекта состоит из 5 этапов: исследование реализуемости, исследование экономической целесообразности, создание функциональной модели, проектирование и разработка, этап реализации.

При некоторых условиях существует возможность включения в DSDM частей других методик, таких как Rational Unified Process (RUP), Экстремальное программирование, PRINCE2.

DSDM был разработан в Великобритании в 1990-х Консорциумом DSDM. Консорциум DSDM - это ассоциация разработчиков и экспертов в области программного обеспечения, созданная с целью "совместной разработки и продвижения независимого фреймворка RAD" комбинированием лучшего практического опыта участников ассоциации. Консорциумом DSDM - это некоммерческая организация независимых разработчиков, которые владеют и управляют фреймворком DSDM. Первая версия фреймворка была завершена в январе 1995 года и опубликована в феврале 1995 года. В июле 2006 года была представлена открытая версия DSDM 4.2, которая стала доступна частным лицам для просмотра и использования. Тем не менее, все, кто распространяет DSDM должны быть членами этого некоммерческого консорциума.

Принципы.

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

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

• Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше - это всегда лучше, чем поставить всё идеально сделанное в конце».

• Анализ поставок версий с предыдущей итерации учитывается на последующей.

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

• Разработка - итеративная и инкрементная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения.

• Любые изменения во время разработки - обратимы.

• Требования устанавливаются на высоком уровне прежде, чем начнётся проект.

• Тестирование интегрировано в жизненный цикл разработки.

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

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

Два примера проектов, для которых DSDM не очень подходит:

• проекты, критичные по безопасности - расширенное тестирование и утверждение в таких проектах конфликтуют с целью метода DSDM уложится в сроки и в бюджет.

• проекты, чья цель произвести компоненты многоразового использования - требования в таких проектах слишком высоки и не укладываются в принцип 80/20.

Жизненный цикл проекта.

• Три стадии DSDM.

Фреймворк DSDM состоит из трёх последовательных стадий, которые называются предпроектная стадия, стадия жизненного цикла проекта и постпроектная стадия. Стадия жизненного цикла проекта - самая продуманная и детально разработанная из всех остальных. Она состоит из пяти этапов, которые формируют итеративный, инкрементный подход к разработке информационных систем. Эти три фазы и соответствующие этапы будут более подробно описаны в последующих разделах. Для каждой стадии или этапа будут рассмотрены самые важные функции и будут представлены результаты.

• Стадия 1 - Предпроектная. На этой стадии определяются вероятные проекты, происходит выделение средств и определение проектной команды. Решение задач на этой стадии поможет избежать проблем на более поздних стадиях проекта.

• Стадия 2 - Жизненный цикл проекта. На рисунке ниже изображена данная стадия. На нём показаны 5 этапов, которые нужно пройти проекту, чтобы стать информационной системой. Первые два этапа, исследование реализуемости и исследование экономической целесообразности, идут последовательно и дополняют друг друга. После завершения этих этапов, происходит итеративная и инкрементная разработка системы в этапах: создание функциональной модели, проектирование и разработка, этап реализации. Итеративная и инкрементная природа DSDM будет описана далее.

• Стадия 3 - Постпроектная. На этой стадии обеспечивается эффективная работа системы. Это достигается за счёт поддержания проекта, его улучшения и исправления ошибок согласно принципам DSDM. Поддержка проекта осуществляется продолжением разработки, основанной на итеративной и инкрементной природе DSDM. Вместо того, чтобы закончить проект за один цикл обычно возвращаются к предыдущим стадиям или этапам, чтобы улучшить продукт.

Ниже на диаграмме представлен весь жизненный цикл проекта. Эта диаграмма описывает итеративную разработку DSDM. Описание каждого этапа будет представлено ниже.

Диаграмма жизненного цикла проекта

Четыре этапа стадии жизненного цикла проекта

Этап 1А: Исследование реализуемости

В течение этого этапа, проверяется реализуемость проекта в рамках DSDM. Предпосылки для использования DSDM проверяются ответом на вопросы: «Может ли данный проект удовлетворить необходимым экономическим требованиям?», «Проект подходит для использования метода DSDM?» и «Какие риски в этом проекте самые важные?». Наиболее важный метод на этом этапе - использование рабочих групп.

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

Этап 1Б: Исследование экономической целесообразности.

Исследование экономической целесообразности расширяет и дополняет этап исследования реализуемости. После того как проект был признан реализуемым в рамках DSDM, на этой стадии проверяются бизнес-процессы, происходит вовлечение групп пользователей и анализ их требований и пожеланий. И опять же самым востребованным методом на данном этапе является использование рабочих групп. В рамках рабочих групп участники проекта собираются, чтобы обсудить планируемую систему. Информация полученная после данных мероприятий собирается в список требований. Важное свойство этого списка - распределение приоритетов среди требований. Эти требования распределены согласно методу MoSCoW. На основе полученной очерёдности создаётся план разработки, который будет ориентиром для всего проекта.

Для создания этого плана применяться очень важная для проекта методика - тайм-боксинг. Эта методика обязательна для достижения целей DSDM - уложится в сроки и в бюджет, и при этом сохранить необходимое качество продукта. Архитектура системы - ещё одно подспорье в управлении разработкой информационной системы. Итогом данного этапа является описание сферы коммерческой деятельности, в котором содержится context of the project within the company, описание архитектуры системы, предоставляющее первоначальную глобальную архитектуру информационной системы, находящейся в разработке, и план разработки, котором обозначены наиболее важные шаги в процессе разработки. В основе этих двух документов лежит список требований. Протокол возможных рисков дополняется данными, полученными на этом этапе.

Этап 2: Создание функциональной модели

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

• Определение функционального прототипа: определение функционала, который будет заложен в прототипе на данном этапе.

• Согласование планов: происходит согласование как и в какие сроки должен быть разработан функционал прототипа.

• Создание функционального прототипа: разработать прототип. Изучить и доработать прототип на данной итерации согласно функциональному прототипу, полученному на предыдущих итерациях.

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

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

Этап 3: Проектирование и разработка

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

• Определение конструктивного прототипа: определение функциональных и нефункциональных требований, которые должны быть в системе.

• Согласование планов: происходит согласование как и в какие сроки должны быть реализованы поставленные требования.

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

• Анализ конструктивного прототипа: проверить исправность спроектированной системы. На этом подэтапе применяется тестирование и пересмотр результатов. Для создания пользовательской документации используются протокол испытания и отзывы пользователей.

Итог этапа - создание конструктивного прототипа для тестирования пользователями. Протестированная система переходит на следующий этап. На данном этапе внешний вид и функционал системы в общем готовы. Ещё один итог - создание пользовательской документации.

Этап 4: Реализация.

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

• Утверждение системы пользователем: конечные пользователи утверждают протестированную систему для последующей реализации и создания руководства.

• Обучение пользователей: обучение будущего пользователя работе с системой. Результат подэтапа - контингент обученных пользователей.

• Реализация: реализация протестированной системы среди пользователей.

• Анализ рынка системы: анализ воздействия выпущенной системы на рынок. Главный вопрос - достигнута ли цель, поставленная при проектировании системы. Основываясь на этом проект переходит на следующую стадию (постпроектную) или возвращается на предыдущую для доработки.

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

Этап создания функциональной модели DSDM.

Модель мета-данных.

Связи между понятиями на этапе создания функциональной модели показаны на рисунке ниже.

Модель мета-данных.

Модель развития процесса.

Работа по определению функционального прототипа заключается в определении функционала, который будет присутствовать в прототипе на данной итерации. Аналитика и программирование закончено; прототипы собраны; и опыт полученный от них использован для улучшения моделей анализа (а также основывается на обновлённых списке требований и протоколе возможных рисков). Построенные прототипы не выбрасываются, а понемногу доводятся до необходимого качества, чтобы потом включить в готовую систему. Согласованный график работ необходим, чтобы определить когда и в какие сроки будет реализовано прототипирование; он расширяет расписание и план прототипирования. А тестирование, проводящееся в течение всего процесса, также является непременной частью этого этапа и включается в процесс анализа прототипа сразу после того, как прототип будет построен. Протокол испытания также будет использован для анализа прототипа и создания документа анализа. Ниже представлена диаграмма данного процесса.

Диаграмма создания функциональной модели.

Основные методики DSDM

• Тайм-боксинг - одна из основных методик DSDM. Она используется, чтобы достичь главных целей DSDM - разработать информационную систему в сроки, уложиться в бюджет и при этом сохранить качество. Основная идея тайм-боксинга - разделить весь проект на части, каждая со своим бюджетом и сроками выполнения. Для каждой такой части выбираются требования, которые были распределены по принципу MoSCoW. Так как время и бюджет фиксированы, единственнное, что можно поменять, - это требования. Так, если проект выбивается из графика или выходит за рамки бюджета, требования с наименьшим приоритетом опускаются. Это не означает, что получится неготовый продукт. Исходя из принципа 20/80 80% проекта получается из 20% требований. Поэтому, как только эти самые важные 20% требований реализованы в системе, она удовлетворяет экономическими требованиям. Стоит заметить, что ни одна система не была идеально построена с первого раза.

• MoSCoW - предоставляет путь распределения объектов по приоритетам. В контексте DSDM метод MoSCoW используется для распределения по приоритетам требования. Эта аббревиатура расшифровывается так:

MUST - требование ДОЛЖНО удовлетворять экономическим нуждам.

SHOULD - СЛЕДУЕТ ли выполнять это требование, если от него не зависит успех проекта.

COULD - НУЖНО ли оставить это требование, если оно не действует на деловую потребность проекта.

WOULD - МОЖНО ли отложить выполнение требования, если ещё есть время.

• Прототипирование -'та методика относится к созданию прототипов системы во время разработки на ранних этапах. Она позволяет выявить недостатки в системе и позволяет будущим пользователям протестировать её. Таким образом реализовано вовлечение пользователя в работу - один из ключевых факторов успеха метода DSDM.

• Тестирование - третья важная сторона достижения цели DSDM - создать информационную систему высокого качества. Чтобы этого добиться, метод DSDM настаивает на проведении тестирования на каждой итерации. Команда проекта вольна сама выбирать способ управления тестированием.

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

• Моделирование - эта методика обязательна и используется с целью визуализировать в виде диаграмм отдельную сторону системы или сферы деятельности, над которыми идёт работа. Моделирование даёт лучшее понимание всей проектной команде сферы деловой активности проекта.

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

Итеративная и инкрементная природа DSDM

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

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

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

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

Факторы, необходимые для успеха метода DSDM

В рамках DSDM существуют следующие факторы, которые влияют на успех проекта.

• Первое - принятие методики DSDM руководством и всеми работниками. Это обеспечивает мотивацию всех участников с момента запуска проекта и их последующую вовлечённость.

• Второй фактор следует из первого - готовность руководства обеспечить вовлечённость конечных пользователей в работу над проектом. Процесс прототипирования требует большой вовлечённости пользователей в тестирование и оценивание функциональных прототипов.

• Третье - проектная команда. Она должна состоять из опытных членов и в итоге стать постояннным объединением. Важная проблема - доверие и взаимопонимание в проектной команде. Это означает, что команда обладает правом и возможностью принимать важные решения о проекте без формального согласования с руководством, что могло бы отнять много времени. Чтобы команда могла успешно работать над проектом, ей нужны необходимые средства - среда разработки, инструменты для управления проектом и т.д.

• Четвёртое. DSDM выступает за благосклонные отношения между разработчиком и покупателем. Это касается проектов, которые разрабатываются внутри самих компаний, а также с использованием сторонних подрядчиков.

Сравнение с другими методами разработки информационных систем

Уже было разработано и применено в деле множество методов разработки информационных систем. Например, Structured Systems Analysis and Design Method (SSADM), методы быстрой разработки приложений RAD, методы ООП. Большинство этих методом похожи друг на друга и на DSDM. Метод экстремального программирования также использует итеративный подход к разработке информационных систем с привлечением пользователей.

Метод Rational Unified Process - самый похожий на DSDM, также является динамическим методом разработки информационных систем. И опять же в нём применяется итеративный подход в разработке.

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

И последнее - взаимопонимание и общение между всеми участниками и их вовлечённость в проект.