Человеческий фактор

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

Варианты организации персонала

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

Управление взаимодействием

Личный опыт автора, да и  многих других, показывает, что количество разработчиков, с которыми каждому из разработчиков необходимо регулярно общаться, составляет от трех до семи человек. (Хэмфри предлагает от четырех до восьми человек.) Результаты различных опытов по определению количества членов команды для наиболее эффективной работы сильно разнятся. Экстремальные значения, которые могут быть полезны при определении численности команды, приведены на рис. 2.3. С одной стороны, разработчик может работать без регулярного индивидуального общения с кем бы то ни было. Однако такая изоляция обычно приводит к непониманию разработчиком предъявляемых к нему требований и, как следствие, к относительно низкому уровню эффективности. С другой стороны, разработчик может работать в такой большой команде, что из-за постоянного общения с каждым из коллег у него не останется времени на собственно разработку. Это снова приводит к относительно низкому уровню эффективности. В частности, регулярное общение означает разговор с кем-либо в течение примерно двух часов в неделю. Таким образом, если инженер регулярно общается с десятью своими коллегами, то добрая половина его рабочего времени проходит в разговорах. Организаторы проектов, планирующие проекты с командами в двадцать, а то и в сто человек, обязательно должны учитывать все вышенаписанное.

26. Архитектуры, основанные на потоках  данных.

Для представления некоторых  приложений наилучшим образом подходят потоки данных между процессами обработки данных. Такое представление иллюстрируют диаграммы потоков данных (DFD — Data Flow Diagram). Каждый процесс обработки данных на диаграмме потоков данных проектируется независимо от других. Данные приходят из различных источников, например от пользователя, и, в конечном итоге, возвращаются к пользователю или в приемники данных, такие как база данных счетов. Диаграмма потоков данных для банковского приложения представлена на рис. 5.14.

Данные передаются от пользователя к процессу Получение депозита. Далее процесс Получение депозита посылает номер счета и размер депозита процессу, проверяющему данные на совместимость. Если данные корректны, то они могут быть отправлены процессу, создающему транзакцию, и т. д. Например, процесс Создание транзакции запроса сам по себе может быть разбит на более подробные диаграммы потоков данных.

Архитектура потоков данных, относящаяся к архитектурам типа каналы и фильтры, представлена на рис. 5.15. Такие архитектуры потоков данных состоят из процессов (фильтров), способных в любой момент времени принять потоки как входную информацию (последовательность данных единообразного вида). Каждый фильтр должен проектироваться независимо от других. Такая архитектура может быть легко реализована с помощью каналов Unix.

Архитектура каналов и  фильтров имеет явное преимущество — модульность. Пример приложения с такой архитектурой показан на рис. 5.16. Это приложение обслуживает транзакции счетов, приходящие в случайные моменты времени по линиям связи. Архитектура содержит шаг для регистрации транзакции в случае отказа системы. Функция снятие() получает в качестве входного параметра символьную строку вида ДжонДоуНомерСчета12345Cyммat$3500.00 или ДжонДоуНомерСчета12345Cyммat$3500.00, а также банковский адрес вида НомерБанка9876. Процессы, изображенные в эллипсах, ожидают появления значения на входе, для того чтобы начать свою работу.

В общем случае не существует унифицированного способа изображения  диаграммы потоков данных для моделей классов. Однако функциональные модули диаграммы потоков данных могут иногда указывать прямо на методы классов. Примером является диаграмма на рис. 5.16.

Благодаря росту объемов распределенных вычислений увеличивается количество приложений с потоко-ориентированными вычислениями. Причиной является тот факт, что передача данных зачастую осуществляется в виде форматированных символьных строк. Такой способ передачи данных реализован, например, в удаленном вызове метода (RMI — Remote Method Invocation) в Java. RMI преобразует передаваемые объекты в символьные строки. Кроме того, часто ввод-вывод также бывает реализован с применением потоков, поэтому использование ввода-вывода в таких языках, как Java, как правило, аналогично процессам-фильтрам.

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

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

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

27. Создание структуры ответственности.  Матричная организация.

Иерархическая структура управления (рис. 2.4) является одним из предельных 
вариантов структуры управления. В этой организации существует главный управляющий - это Эйприл Смит, с тремя подчиненными управляющими. Лайл Герберт несет ответственность за аспекты проекта, связанные с маркетингом. Очевидно, что отдел маркетинга будет связываться с заказчиками для поддержания уверенности в том, что продукт удовлетворяет заказчика. Куин Паркер и его подчиненный Верн Крупп отвечают за контроль качества. Достоинства этой организационной схемы заключаются в том, что каждый понимает линии руководства и пути принятия решений, к тому же количество людей, с которыми каждый из сотрудников должен регулярно общаться, является удовлетворительным. Недостатком является то, что члены команды не участвуют в постановке задач, которые в основном ставятся перед ними начальством. При прочих равных оостоятельствах это один из наиболее безопасных путей организации проекта. Крупные проекты, организованные в таком иерархическом стиле, требуют проработки более широких и глубоких организационных схем.

Другим предельным вариантом  структуры управления является команда равных, состоящая из сообщества сотрудников с одинаковыми правами и возможностями. Достоинством такой организации является огромный потенциал мотивации, который появляется благодаря равноправному партнерству в проекте. Зачастую эта структура прекрасно работает, если рабочая группа — небольшая, достаточно компетентная и сработанная. К недостаткам относятся трудности при решении разногласий и тот факт, что «никто ни за что не отвечает». Командный процесс разработки программного обеспечения, изобретенный Хэмфри [51], это своеобразный набор путеводных нитей для таких команд. В конечном счете должна быть получена смесь коллегиального участия и личной ответственности в соответствии с размерами проекта, его природой, зрелостью и привлекаемыми к проекту людьми.

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

Идея состоит в том, что участники команды равны, за исключением Гила Варнера, который является ответственным за проектирование. В идеале он поощряет участие всех разработчиков в проектировании, но если требуется, принимает решения единолично. Более детально возможная организация команды показана ниже. Если в команде пять участников, то один и тот же участник может быть ответственным за требования и по реализации, поскольку в каждый конкретный момент времени только одно из двух требует повышенной активности. Ответственность за требования можно распределить между всеми, но кто-то конкретно должен отвечать за SRS. Можно меняться ролями примерно раз в три месяца с целью приобретения опыта. Поскольку каждая роль критична, разумно предусмотреть систему подстраховки. Страхующий инженер берет обязанности на себя, если назначенный лидер не может их выполнить по каким-то причинам. Страхующий обязательно инспектирует всю работу страхуемого, чтобы быть в курсе дела.

С ростом числа участников проекта  организация команды равных становится 
невозможной, поскольку количество связей но взаимодействию растет квадра- 
тично. Действительно, между тремя участниками есть три связи, четыре участника имеют шесть связей, пять человек — десять связей, то есть п человек имеют (и — 1) + (п - 2) + ... + 1 - п (и - 1)/2 связей (каждый с каждым).

 Таким образом, 100 человек должны участвовать в 4950 взаимодействиях! Для больших проектов альтернативой является схема организации, приведенная на рис. 2.6. В этой схеме команды равных небольшие, но один участник команды выделен для взаимодействия с другими командами. Такая схема сохраняет преимущества небольших команд, но позволяет большому количеству людей создавать большие приложения.

Вообще говоря, системы  отчетности на практике имеют более  сложную и комплексную структуру, чем в проектно-ориентированных  организациях. Это происходит из-за использования матричной структуры. В матричных организациях служащие относятся к функциональным подразделениям (например, отдел разработки, отдел продаж и т. п.) и выделяются этими подразделениями для участия в том или ином проекте (табл. 2.1). Таким образом, начальник программного разработчика, отвечающий за своего подчиненного, будет членом функционального подразделения программной разработки. Однако в каждом проекте, в котором разработчик принимает участие, он подчиняется лидеру проекта. Обычно разработчиков на постоянной основе привлекают не более чем к двум проектам. Например, если бы некая организация, использующая иерархическую организацию проекта (см. рис. 2.4), имела матричную структуру, то Лайл Герберт был бы членом отдела маркетинга. При этом его начальником был бы не Эйприл Смит, а управляющий отдела маркетинга, который консультировался бы с Эйприлом при оценке работы своих подчиненных. Основным достоинством матричных организаций является 
профессионализм и возможность улучшения навыков. К недостаткам относится 
нечеткость в линиях субординации. Довольно часто компании стараются найти 
золотую середину между матричной и проектно-ориентированной структурами.

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

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

Клиент-серверная архитектура

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