Разработка программного обеспечения, кроме достаточно сложного технического аспекта, имеет сложный организационный или даже психологический аспект.

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

Вопрос в том, как построить модель отношений заказчика и разработчика с учетом интересов обеих сторон и без потери качества?

Современные технологии разработки ПО рекомендуют определять команду как три независимые административно стороны.

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

Итак, сторона заказчика имеет следующие ключевые роли: менеджер продукта и бизнес-аналитик.

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

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

Сторона разработчика: менеджер программы, аналитик, программист, тестировщик.

Менеджер программы — это главный технический специалист проекта, он является хранителем спецификации и заинтересован в ее минимальных изменениях во время разработки.

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

Программист — непосредственно кодировщик.

Тестировщик — специалист по тестированию, он отвечает за соответствие системы ее спецификации.

Сторона качества: бизнес-аналитик и технолог.

Бизнес-аналитик — специалист по предметной области вообще, независимо от конкретного предприятия.

Технолог — специалист по технологии, контролирующий правильность ее использования.

В реальности каждая сторона работает в противовес двум остальным и необходима для сохранения общего баланса.

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

Проблема взаимодействия возникает уже при работе группы из четырех и более человек. Для управления их работой необходим руководитель.

Решением этой проблемы может стать организация бригад, например бригады главного программиста, если рассматривать на примере программистов. Бригада должна включать от 3 до 7 человек. Число 10 является верхней границей численности бригады. Это обусловлено требованием максимальной управляемости коллектива.

В бригаде в зависимости от квалификации выделяют следующих специалистов.

Руководитель бригады (например, главный программист) — это превосходно подготовленный, творчески мыслящий, наделенный организацион­ными способностями специалист. Он выполняет работу верхнего уровня, в том числе распределение работы внутри бригады.

Заместитель руководителя бригады (например, старший программист) поддерживает тесную связь с руководителем бригады и дорабатывает более мелкие вопросы. При обсуждении проекта заместитель должен выступать в роли оппонента руководителю бригады.

Непосредственно исполнители (например, младшие программисты) — два или три "менее опытных" (но не "менее способных") специалиста. Они выполняют работу нижнего уровня, определенную руководителем бригады.

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

Администратор отвечает за распределение времени, подбор кадров, размещение исполнителей, финансирование, поддержку связи с высшим руководством.

Библиотекарь ведет системную библиотеку, например, библиотеку модулей, используемых в оперативном режиме. Все изменения в программные модули вносит только библиотекарь. Он также ведет системную документацию — системный журнал.

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

Секретарь выполняет обычную работу секретаря.

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

Поэтому после первоначального определения функций, которые должно выполнять разрабатываемое ПО, проект распределяется между различными командами раз­работчиков (рис. 12.1).

Рис. 12.1. Группы специалистов, занятых в разработке ПО

(n — количество функций ПО)

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

Результатом стадии должны быть:

- общая информационная модель системы;

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

- точно определенные интерфейсы между автономно разрабатываемыми подсистемами (те данные, которые передаются между ними);

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

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