Технические роли в бригаде

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

Заказчик – ставит задачу, уточняет и контролирует. Знать приоритеты работ и принимает решения в соответствии с ними.

Тестер – следит за регулярными запусками тестов.

Ревизор – следит за общей картиной разработки и контролирует успешность продвижения к цели.

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

Консультант – приносит в команду знания для решения возникающих проблем.

Большой босс – руководит проектом и принимает основные решения. Он же за все и отвечает.

Психологические роли в бригаде

Председатель – выбирает путь, по которому команда движется к цели. Умеет обнаружить сильные и слабые стороны команды.

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

Генератор идей – выдвигает новые идеи, пытается внедрять радикальные технологии.

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

Рабочая пчелка – превращает планы и концепции в практические рабочие процедуры.

Опора команды – поддерживает силу духа, способствует подъему командного настроя. Добытчик – налаживает внешние контакты, которые могут быть полезными для команды.

Завершающий – поддерживает в команде настойчивость в достижении цели. Играет доминирующую роль на стадии финального тестирования и сдачи.

Каждый участник может играть несколько ролей.

5. Архитектура систем

5.1. Причины декомпозиции программы на модули (содержательные и технические аспекты). Декомпозиция как способ борьбы со сложностью

Сложность программной системы – одна из основных проблем программирования. Человек по своей природе способен контролировать весьма ограниченное количество объектов, тогда как в процессе написание или исследовании программ требуется анализировать исключительно большое количество ситуаций. Сложность возникает не столько от количества элементов программной системы, сколько от количества связей между ними. Так, если система состоит из N элементов, количество потенциальных путей между ними – N!, то есть при N>7 анализировать её становится практически невозможно. На самом деле в системе реализуются далеко не все потенциальные связи между элементами, но всё равно, считается, что сложность её растёт экспоненциально в зависимости от объёма.

Пусть T(N) – функция сложности, то есть, время, необходимое для написания или понимания программы размером в N строк. Тогда, учитывая экспоненциальную сложность, получаем T(N₁+N₂) > T(N₁)+T(N₂). Если считать, что функциональность программы определяется некоторым необходимым объёмом кода N, получается, что написание кода программы, реализующей эту функциональность, сложнее, чем написание двух фрагментов с той же общей функциональностью и с тем же суммарным объёмом. Таким образом, стремление к уменьшению сложности программы приводит к необходимости декомпозиции её на меньшие фрагменты – модули, реализующие ту же функциональность.

Существует довольно много определений модуля, но все они сводятся практически к одному и тому же: модуль должен быть относительно независимым фрагментом какого-то текста. Если речь идёт о программе, то это фрагмент текста программы. Далее под программным модулем будем понимать отдельно программируемый, транслируемый и отлаживаемый программный фрагмент.

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

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

Существуют и другие мотивы разбиения программы на модули, которые приводят разные авторы, например, [Жоголев-14]. В разное время значимость отдельных аргументов как за, так и против, менялась, некоторые аргументы в пользу декомпозиции, такие, как уменьшение времени трансляции, выглядят анахронизмом. В целом можно рассматривать как содержательные, так и технические мотивы. Заметим, что исторически раньше возникли технические проблемы, связанные с размещением программы в оперативной памяти, но сейчас они рассматриваются как вторичные.

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

• уменьшение сложности программной системы, о чём уже говорилось;

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

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

• упрощение планирования коллективной работы над программным проектом;

• возможность существенного упрощения изменяемости системы в процессе её сопровождения и, как следствие, увеличение срока её эксплуатации.

К техническим мотивам декомпозиции можно отнести следующие:

• возможность многократного использования уже существующего отлаженного кода (иногда этот мотив относят к содержательным);

• сокращение записи при программировании (отсутствие дублирования текста);

• удобство редактирования и наглядность – модуль в силу своего размера не способствует текстуальному разнесению логически связанного текста;

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

• уменьшение времени трансляции – в настоящее время это не актуально.