Электронные библиотеки и инструментарий Internet’a
Коллекции информационных ресурсов;
БД Интернета;
Поисковые средства;
Системы AI (мультиагенты).
Репозитории.
Создаются на время разработки программного продукта при коллективной разработке. Представляют собой хранилище информации, связанной с проектом разработки программного продукта в течение всего его жизненного цикла.
Три уровня репозитория:
Модельный;
Программного интерфейса;
Окружения.
Средства поддержки коллективной разработки
Проблема разделения ресурсов.
Системы разделения файлов.
Системы управления версиями файлов (для отслеживания изменений между версиями файлов и разделения доступа к ним).
Системы управления правами пользователей (для обмена результатами работы между отдельными разработчиками через объединение результатов в выделенном рабочем пространстве). Мастер пространство.
Системы синхронизации удаленных производств. Решаются проблемы организации и пересылки изменений и их синхронизации.
Средств поддержки работы виртуальных групп.
Организация работы группы людей в интерактивном режиме: аудиоконференции, чаты, доски объявлений, форумы, электронная почта.
23
Для создания сложных программных приложений в современных условиях применяются CASE-технологии и CASE-средства. CASE-технологии представляют собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных программных систем с применением комплекса взаимосвязанных средств автоматизации. CASE- средства – системы автоматизированной разработки программного обеспечения (ПО) – существенно сокращают сроки и затраты разработки, оказывая помощь инженеру в проведении рутинных операций, облегчая его работу на самых разных этапах жизненного цикла разработки ПО. Одной из наиболее известных объектно-ориентированных CASE-систем является Rational Rose. В данной лабораторной работе рассматривается порядок применения Rational Rose при формировании требований, анализе, проектировании и генерации программного кода.
Процесс разработки ПО состоит из последовательности шагов, использующих методы, средства и процедуры. Эти последовательности шагов часто называют парадигмами технологии разработки программного обеспечения (ТРПО). Применение парадигм ТРПО гарантирует систематический, упорядоченный подход к промышленной разработке, использованию и сопровождению ПО. Фактически парадигмы вносят в процесс создания ПО организующее инженерное начало, необходимость которого трудно переоценить.
Средства (утилиты) ТРПО направлены на автоматизированную или автоматическую поддержку методов. Методы обеспечивают решение задач планирования и оценки проекта, анализа системных и программных требований, проектирования алгоритмов, структур данных и программных структур, кодирования, тестирования и сопровождения. В целях совместного применения утилиты могут объединяться в системы автоматизированной разработки ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой). Процедуры определяют порядок применения методов и средств для формирования отчетов требуемых форм, контроля качества, координации изменений и т.п. Они соединяют методы и средства в непрерывную технологическую цепочку разработки. CASE-технологии меняют все этапы жизненного цикла ПО
UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Он является простым и мощным средством моделирования, которое может быть эффективно использовано для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения.
Описание языка UML включает:
? семантику языка UML. Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML. Семантика определяется для двух видов объектных моделей: структурных моделей и моделей поведения;
? нотацию языка UML. Содержит описание отдельных семантических элементов, графическую нотацию для визуального представления семантики языка UML.
Визуальное моделирование с использованием нотации UML можно представить как некоторый процесс поуровнего спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме диаграммы вариантов использования (Use Case diagram), которая описывает функциональное назначение системы. Диаграмма Use Case является исходным концептуальным представлением (концептуальной моделью) системы в процессе ее проектирования и разработки. Она определяет поведение системы с точки зрения пользователя и рассматривается как главное средство для первичного моделирования динамики системы. Диаграмма Use Case используется для выяснения требований к разрабатываемой системе, фиксации этих требований в форме, которая позволит вести дальнейшую разработку. Диаграммы Use Case также называют диаграммами прецедентов.
Разработка диаграммы вариантов использования преследует следующие цели:
? определение общих границ и контекста моделируемой предметной области на начальных этапах проектирования системы;
? формулировка общих требований к функциональному поведению проектируемой системы;
? разработка исходной концептуальной модели системы для ее последующей детализации в форме логических и физических моделей;
? подготовка исходной документации для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Основное назначение диаграмм Use Case – определение требований заказчика к будущему программному приложению. Суть данной диаграммы состоит в следующем: проектируемая система представляется в форме так называемых вариантов использования, с которыми взаимодействуют некоторые внешние сущности или актеры. При этом актером или действующим лицом называется любой объект, субъект или система, взаимодействующая с моделируемой системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит разработчик. В свою очередь вариант использования служит для описания сервисов, которые система предоставляет актеру, т.е. каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. Каким образом будет реализовано взаимодействие актеров с системой и собственно вариантов использования, данная диаграмма не показывает. В этом смысле диаграмма Use Case ассоциируется с моделью "черного ящика".
Диаграмма Use Case представляет собой граф специального вида. В состав диаграмм входят элементы Use Case (варианты использования), актеры, а также отношения (зависимости, обобщения, ассоциации и др.). Актеры и элементы Use Case являются вершинами графа. Актеры представляют внешний мир, нуждающийся в работе системы, элементы Use Case представляют действия, выполняемые системой в интересах актеров. Отношения – дуги графа. Диаграммы Use Case могут включать примечания и ограничения и содержать пакеты, используемые для группировки элементов модели в крупные фрагменты.
Актер – это роль объекта вне системы, который прямо взаимодействует с ее частью – конкретным элементом (элементом Use Case). Различают актеров и пользователей. Пользователь – это физический объект, который использует систему. Он может играть несколько ролей и поэтому может моделироваться несколькими актерами. Справедливо и другое – актером могут быть разные пользователи. Например, для коммерческого летательного аппарата можно выделить двух актеров: пилота и кассира. Сидоров – пользователь, который иногда действует как пилот, а иногда как кассир. В зависимости от роли Сидоров взаимодействует с разными элементами Use Case.
Элемент Use Case – это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдельного актера видимый результат. Один актер может использовать несколько элементов Use Case, и наоборот один элемент Use Case может иметь несколько актеров, использующих его. Каждый элемент Use Case задает определенный путь использования системы. Набор всех элементов Use Case определяет полные функциональные возможности системы.
Между актером и элементом Use Case возможен только один вид отношения – ассоциация, отображающая их взаимодействие. Как и любая другая ассоциация, она может быть помечена именем ролями и мощностью. Между актерами допустимо отношение обобщения, означающее, что экземпляр потомка может взаимодействовать с такими же разновидностями экземпляров Use Case, что и экземпляр родителя. Между элементами Use Case определены отношение обобщения и две разновидности отношения зависимости – включения и расширения. Отношение обобщения фиксирует, что потомок наследует поведение родителя. Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case, являющийся потомком, может замещать элемент Use Case, являющийся родителем, в любом месте диаграммы. Отношение включения между элементами Use Case означает, что базовый элемент Use Case явно включает поведение другого элемента Use Case в точке, которая определена в базе. Включаемый элемент Use Case никогда не используется самостоятельно – его конкретизация может быть только частью другого, большего элемента Use Case.отношение включения является примером отношения делегации. При этом в отдельное место (включаемый элемент Use Case) помещается определенный набор обязанностей системы. Далее остальные части системы могут агрегировать в себя эти обязанности (при необходимости). Отношение расширения между элементами Use Case означает, что базовый элемент Use Case неявно включает поведение другого элемента Use Case в точке, которая определяется косвенно расширяющим элементом Use Case. Базовый элемент Use Case может быть автономен, но при определенных условиях его поведение может расширяться поведением из другого элемента Use Case. Базовый элемент Use Case может расширяться только в определенных точках - точках расширения. Внутри элемента Use Case может быть дополнительная секция с заголовком Extention points. В этой области перечисляются точки расширения. Отношения расширения применяется для моделирования выбираемого поведения системы. Таким образом, можно отделить обязательное поведение от необязательного поведения. Например, можно использовать отношение расширения для отдельного подпотока, который выполняется только при определенных условиях, находящихся вне поля зрения базового элемента Use Case. Можно моделировать отдельные потоки, вставка которых в определенную точку управляется актером.
Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. При моделировании это позволяет отделять внешнее представление системы от ее внутреннего представления. Поведение элемента Use Case описывается потоком событий. Начальное описание выполняется в текстовой форме, прозрачной для пользователя системы. В потоке событий выделяют: основной поток и альтернативные потоки поведения; как и когда стартует и заканчивается элемент Use Case; когда элемент Use Case взаимодействует с актерами; какими данными обмениваются актер и система. Для уточнения и формализации потоков используют диаграммы последовательности. С помощью диаграммы последовательностей можно описать полный контекст взаимодействий как своеобразный график "жизни" всей совокупности объектов, взаимодействующих между собой для реализации варианта использования программной системы, достижения бизнес-цели или выполнения какой-либо задачи. Обычно одна диаграмма последовательности определяет главный поток в элементе Use Case, а другие диаграммы – потоки исключений. В общем случае каждый элемент Use Case описывает набор последовательностей, в котором каждая последовательность представляет возможный поток событий. Каждая последовательность называется сценарием. Сценарий – конкретная последовательность действий, которая иллюстрирует поведение. Сценарии являются для элемента Use Case почти тем же, чем являются экземпляры для класса. Говорят, что сценарий – это экземпляр элемента Use Case.
Для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования служит диаграмма классов. Диаграмма классов может отражать различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, описывает их внутреннюю структуру и типы отношений. Данная диаграмма служит развитием концептуальной модели проектируемой системы. Диаграмма не содержит представления о временных аспектах функционирования системы и представляет собой конечный граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения. Данная диаграмма состоит из множества элементов, отражающих декларативные знания о предметной области, и является графическим представлением таких структурных взаимосвязей логической модели системы, которые не зависят от времени.
Рассмотренные выше диаграммы отражают концептуальные аспекты построения модели и относятся к логическому уровню представления. Однако полный проект программной системы представляет собой совокупность логических и физических моделей. Для физического представления системы в языке UML используются диаграмма компонентов и диаграмма развертывания.
Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули показывают отношения взаимозависимости между ними.
Диаграмма развертывания требуется для проектирования сетевых и распределенных систем. Она содержит графические изображения процессоров, устройств, процессов и связей между ними и отражает особенности реализации системы в целом.
2.3.2. Rational Rose
Rational Rose – это CASE-система для визуального моделирования объектно-ориентированных программных продуктов. Визуальное моделирование - процесс графического описания разрабатываемого ПО. Процесс работы над проектом состоит в последовательной разработке канонических диаграмм, которые в совокупности представляют интегрированную модель разрабатываемой программной системы. Хотя последовательность разработки диаграмм в языке UML не определена, для этой цели можно воспользоваться рекомендациями рационального унифицированного процесса. Рекомендуется начинать работу с общего анализа проблемы и построения диаграммы вариантов использования.
Одним из наиболее мощных свойств Rational Rose является возможность генерации программного кода после построения модели. Для этой цели предоставляется большой выбор языков программирования и схем баз данных.
На рисунке 3 представлено рабочее окно среды Rational Rose. В его составе можно выделить следующие элементы: строка инструментов, панель «инструменты диаграммы», окно диаграммы, браузер, окно спецификации, окно документации. В окне диаграммы можно создавать, отображать и изменять диаграмму на языке UML. Браузер Rational Rose является инструментом иерархической навигации, позволяющим просматривать названия и пиктограммы, отображающие диаграммы и элементы визуальной модели. Окно спецификации позволяет задать характеристики элемента диаграммы. В поле Documentation этого окна вводится словесное описание данного элемента. Это же описание можно вводить в Окно документации Rational Rose (когда данный элемент выделен в диаграмме).
24. Коллективная разработка
Коллективная разработка.
В зависимости от количества участников и типа взаимодействий между ними выделяют три типа разработок:
1. Авторская (жизненный цикл ПО поддерживается одним человеком) – высокая производительность засчёт исключения межличностных коммуникаций, тех документации, работ по разбиению проекта на составляющие, распределению работ, координации деятельности исполнителей, исключение контроля за работой. Объём авторской разработки в 5-20 раз меньше по сравнению с индустриальными. Меньше количество ошибок. Сравнительно небольшой размер ПО.
2. Коллективная разработка.
Основная задача: разделение труда.
Способы разделения труда от бригады равных соисполнителей до организации в виде жёсткой иерархии. В бригаде равных соисполнителей включают разработчика (программистов, технических писателей, инженеры тестирования, инженеры качества, специалисты по сопровождению продукта, специалисты по продажам)
Командные роли бригады главного программиста: Главный программист,
Дублёр (заместитель главного),
Администратор (менеджер),
Редактор (технический писатель),
Языковед (эксперт в языках программирования),
Инструментальщик,
Отладчик,
Делопроизводитель.
3. Общинная (базарная)
Характеризуется тремя основными факторами: - децентрализованность разработки (нет ограничения по количеству людей – любой может присоединиться к разработке)
- разработка ведётся на базе открытых исходных текстов (тексты должны публиковаться через интернет)
- Большое количество внешних тестеров.
2.2. Группы разработки
Важным элементом успешного создания или модернизации программного продукта является управление группой разработки (далее - командой), а умение "работать в команде" - очень важное качество для специалиста, наряду с квалификацией и опытом. В современных условиях часто требуется создать инфраструктуру, приспособленную к сложности и неопределенности проектов
Модель команды постоянно эволюционировала в процессе развития дисциплины управления процессом разработки. Но основными определяющими признаками этой модели всегда являлись уровень мобильности персонала и демократизации самой команды. Под демократизацией в дальнейшем мы будем подразумевать степень участия членов команды в принятии решений по проекту. Мобильность персонала - это возможность задействовать работника в нескольких проектах, что позволяет максимально эффективно использовать на предприятии людские ресурсы. Совокупность этих признаков и определяет функциональную гибкость команды, т.е. способность приспособиться к постоянно изменяющимся требованиям и к неопределенности.
Разработка ПС обычно производится в организации, в которой одновременно могут вестись разработки ряда других программных средств. Для управления всеми этими программными проектами используется иерархическая структура управления. Традиционная структура такого управления представлена на рис. 1.
Структура управления разработкой программных средств
Рис. 1.
Во главе этой иерархии находится директор (или вице-президент) программистской организации, отвечающий за управление всеми разработками программных средств. Ему непосредственно подчинены несколько менеджеров сферы разработок и один менеджер по качеству программных средств. В результате общения с потенциальными заказчиками директор принимает решение о начале выполнения какого-либо программного проекта, поручая его одному из менеджеров сферы разработок, а также решение о прекращение того или иного проекта. Он участвует в обсуждении общих организационных требований (ограничений) к программному проекту и возникающих проблем, решение которых требует использования общих ресурсов программистской организации или изменения заказчиком общих требований.
Менеджер сферы разработок отвечает за управление разработками программных средств (систем) определенного типа, например, программные системы в сфере бизнеса, экспертные системы, программные инструменты и инструментальные системы, поддерживающие процессы разработки программных средств, и другие. Ему непосредственно подчинены менеджеры проектов, относящихся к его сфере. Получив поручение директора по выполнению некоторого проекта, он организует формирование коллектива исполнителей по этому проекту (в частности, необходимую вербовку и обучение персонала). Он участвует в обсуждении плана-проспекта программного проекта, относящегося к сфере разработок, за которую он отвечает, а также в обсуждении и решении возникающих проблем в развитии этого проекта. Он организует обобщение опыта разработок программных средств в его сфере и накопление программных средств и документов для повторного использования.
По каждому программному проекту назначается свой менеджер, который управляет развитием этого проекта. Ему непосредственно подчинены лидеры бригад разработчиков. Менеджер проекта осуществляет планирование и составление расписаний работы этих бригад по разработке соответствующего ПС (см. следующий раздел).
Считается крайне нецелесообразным разработка большого ПС (программной системы) одной большой единой бригадой разработчиков. Для этого имеется ряд серьезных причин. В частности, в большой бригаде время, затрачиваемое на общение между ее членами, может быть больше времени, затрачиваемого на собственно разработку. Отрицательное влияние оказывает большая бригада на строение ПС и на интерфейс между отдельными его частями. Все это приводит к снижению надежности ПС. Поэтому обычно большой проект разбивается на несколько относительно независимых подпроектов таким образом, чтобы каждый подпроект мог быть выполнен отдельной небольшой бригадой разработчиков (обычно считается, что в бригаде не должно быть больше 8-10 членов). При этом архитектура ПС должна быть такой, чтобы между программными подсистемами, разрабатываемыми независимыми бригадами, был достаточно простой и хорошо определенный системный интерфейс.
Важное место в управлении разработкой ПС отводится управлению обеспечением качества. Для руководства этой деятельностью назначается специальный менеджер, подчиненный непосредственно директору, – менеджер по качеству. Ему непосредственно подчинены формируемые бригады по контролю качества. Эти бригады работают с отдельными проектами, но непосредственно соответствующим менеджерам проектов не подчинены, сохраняя тем самым свою независимость от них.
Управление обеспечением качества означает контроль качества каждой работы, выполняемой разработчиками в рамках программного проекта, контроль каждого документа, включаемого в ПС. Качество ПС не может быть добавлено к ПС после того, как оно будет уже создано. Качество ПС формируется постепенно в процессе всей разработки ПС, в каждой отдельной работе, выполняемой по программному проекту. Поэтому для каждой такой работы, прежде, чем она получит одобрение и будет считаться завершенной, организуется смотр (review) соответствующей бригадой по контролю качества. Этот смотр существенно отличается от контроля, осуществляемого разработчиками в конце каждого этапа разработки, так как последний является техническим процессом, связанным с обнаружением ошибок, тогда как смотр по контролю качества является функцией управления разработкой и связан с оценкой того, насколько результаты этой работы согласуются с декларированными требованиями относительно качества ПС.
Наиболее употребительны три подхода к организации бригад разработчиков:
обычные бригады,
бригады ведущего программиста.
неформальные демократические бригады,
В основе обычной бригады лежит древовидная модель, которая возникла на заре "компьютерной эры" и была заимствована из стандартной модели управления предприятием. В основе этой модели лежит принцип единоначалия с элементами авторитарной власти, который обеспечивает высокую степень надежности, устойчивости и управляемости команды. Иерархическая модель является самой известной и распространенной моделью. Она легко масштабируема и может применяться в командах от десятков до тысяч работников, но характеризуется низкой демократичностью и низкой мобильностью персонала. Модель хуже всех приспособлена к частой смене технологий разработки и идеологий процесса проектирования. Также необходимо отметить, что эффективность данной модели сильно зависит от личных качеств руководителя: отрицательные личные качества руководителей оказывают негативное воздействие на эффективность работы команды, причем это воздействие непропорционально увеличивается с ростом уровня в дереве субординации.
В обычной бригаде старший программист (лидер бригады) непосредственно руководит работой младших программистов. Недостатки такой организации непосредственно связаны со спецификой разработки ПС: программисты разрабатывают сильно связанные части программной подсистемы, сам процесс разработки состоит из многих этапов, каждый из которых требует особенных способностей от программиста, ошибки отдельного программиста могут препятствовать работе других программистов. Успех работы такой бригады достигается в том случае, когда ее руководитель является компетентным программистом, способным предъявлять к членам бригады разумные требования и умеющим поощрять хорошую работу.
Модель бригады главного программиста (или модель хирургической бригады) появилась во время первой технологической революции в программировании в 70-е годы. Долгое время эта модель являлась доминирующей при разработке программного обеспечения. При этом, главный программист выполняет роль руководителя проекта, а прочие члены бригады ассистируют в определенных рамках своих ролевых функций. Руководитель проекта - это единственный из участников, который вовлечен в проект от начала до конца. Такой модели присуща довольно высокая степень мобильности, однако демократизация остается по-прежнему низкой (поскольку главный программист единолично принимает все принципиальные решения по проекту). Вследствие этого проект очень сильно зависит от компетенции и личных качеств главного программиста. Кроме того, велик управленческий риск мгновенной аннигиляции бригады, если что-то случается с руководителем проекта. Второй пилот в бригаде должен тщательно отслеживать все действия главного программиста. Это несколько снижает риск аннигиляции, но не устраняет его полностью.
В бригаде ведущего программиста за разработку порученной программной подсистемы несет полную ответственность один человек, называемый ведущим программистом (chief programmer) и являющийся лидером бригады: он сам конструирует эту подсистему, составляет и отлаживает необходимые программы, пишет документацию к подсистеме. Ведущий программист выбирается из числа опытных и одаренных программистов. Все остальные члены такой бригады, в основном, создают условия для наиболее продуктивной работы ведущего программиста. Организацию такой бригады обычно сравнивают с хирургической бригадой. Ядро бригады ведущего программиста составляют три члена бригады: помимо ведущего программиста в него входит дублер ведущего программиста и администратор базы данных разработки. Дублер ведущего программиста (backup programmer) также является квалифицированным и опытным программистом, способным выполнить любую работу ведущего программиста, но сам он эту работу не делает. Главная его обязанность – быть в курсе всего, что делает ведущий программист. Он выступает в роли оппонента ведущего программиста при обсуждении его идей и предложений, но решения по всем обсуждаемым вопросам принимает единолично ведущий программист. Администратор базы данных разработки (librarian) отвечает за сопровождение всей документации (включая версии программ), возникающей в процессе разработки программной подсистемы, и снабжает членов бригады информацией о текущем состоянии разработки. Эта работа выполняется с помощью соответствующей инструментальной компьютерной поддержки. В зависимости от объема и характера порученной работы в бригаду могут быть включены дополнительные члены, такие как
распорядитель бригады, выполняющий административные функции;
технический редактор, осуществляющий доработку и техническое редактирование документов, написанных ведущим программистом;
инструментальщик, отвечающий за подбор и функционирование программных средств, поддерживающих разработку программной подсистемы;
тестовик, готовящий подходящий набор тестов для отладки разрабатываемой программной подсистемы;
один или несколько младших программистов, осуществляющих кодирование отдельных программных компонент по спецификациям, разработанным ведущим программистом.
Кроме того, к работе бригады может привлекаться для консультации эксперт по языку программирования.
В последние десятилетия, в связи с бурным ростом софтверной индустрии и частыми изменениями технологий и идеологий разработки, появилась необходимость создания модели команды, которой была бы присуща максимальная функциональная гибкость. Так появилась модель команды-сообщества (community team), ярким примером которой является команда Microsoft и методология разработки программных продуктов Microsoft Solutions Framework. Это наиболее демократичная модель, поскольку в ней нет явно выделенного центра. Команда-сообщество - это команда равных. Схематически ее принято изображать в виде цикла, где все роли равноправны и связаны друг с другом. В подобной команде (в отличие от двух других вышеописанных моделей) взаимодействие участников проекта происходит на уровне сотрудничества. К преимуществам данной модели можно отнести: высокую функциональную гибкость, высокую масштабируемость и производительность команды. Однако на пути воплощения в жизнь подобной модели встают несколько существенных преград: а) подбор участников должен вестись не только исходя из компетенции, но и с учетом психологической и социо-культурной совместимости, а также с учетом умения работать в команде (артельного духа); б) для формирования подобной команды нужны равные (одинаково квалифицированные и равно заинтересованные) участники.
В неформальной демократической бригаде поручаемая ей работа обсуждается совместно всеми ее членами, а задания между ее членами распределяются согласованно в зависимости от способностей и опыта этих членов. Один из членов этой бригады является лидером (руководителем) бригады, но он также выполняет и некоторые задания, распределяемые между членами бригады. Неформальные демократические бригады могут весьма успешно справляться с порученной им работой, если большинство членов бригады являются опытными и компетентными специалистами. Если же неформальная демократическая бригада состоит, в основном, из неопытных и некомпетентных членов, в деятельности бригады могут возникать большие трудности. Без наличия в бригаде хотя бы одного квалифицированного и авторитетного члена, способного координировать и направлять работу членов бригады, эти трудности могут привести к неудаче проекта.