student2007Тогда как лучше распределить работу на троих?
ВАРИАНТ 2
1 аналитик/архитектор/главный программист - делает 60% работы
2-е помогают в написании вспомогательных модулей

ВАРИАНТ 3
Разбиваем на модули, каждый пишет свой модуль, потом пытаемся все соединить.Пробовали работать по ВАРИАНТУ 4, который является комбинацией из 2 и 3.

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

Выделенного человека на тестировании не было, но 70% тестирования проводил один из нас.

Проект был сделан успешно, система заработала и была установлена в несколько аэропортов.

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

PS: если вам не удается построить работу так как надо - это еще не значит, что ни у кого это не получалось и не получится.

Сергей ВаскецовУскорение при анализе работы параллельных алгоритмов - это не просто отношение времен выполнения алгоритмов, а приведенное к количеству узлов. Если задача полностью распараллеливается, и 2 процессора ее выполняют вдвое быстрее, N процессоров - в N раз быстрее - ускорение равно 1. Оставляю в качестве домашнего задания придумать ситуацию, когда ускорение может превышать 1, это крайне нетривиальные случаи. Но начать рекомендую с матчасти.Давайте лучше выполним другое домашнее задание.
приведите пример, когда по ВАШЕМУ ОПРЕДЕЛЕНИЮ УСКОРЕНИЯ - задания при распараллеливании или выполнении на 1 одном процессоре - вобще будут иметь ускорение отличное от 1,
при условии, что издержки на переключение задач отсутствуют.

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

Но это все лирика... Потому что весь мир за счет параллельного выполнения пытается сократить АБСОЛЮТНОЕ время выполнения суммы заданий, связанных друг с другом зависимостями.
И использует для этого другие критерии успешности полученного результата.

Сергей Васкецов Belyприведите пример, когда по ВАШЕМУ ОПРЕДЕЛЕНИЮ УСКОРЕНИЯ - задания при распараллеливании или выполнении на 1 одном процессоре - вобще будут иметь ускорение отличное от 1, при условии, что издержки на переключение задач отсутствуют.
Элементарно. Любой пример, где одна ветвь параллельного алгоритма будет ждать результатов от другой. Например, в случае решения уравнений матфизики с граничными условиями.
Берем простой случай - две задачи, вторая задача ждет данные от первой. обе задачи выполняются по 1 минуте.
Принципиально нераспараллеливающийся случай.

Узлов в графе задач - два.
Время выполнения (абсолютное) для одного процессора: t1 + t2 = 2 минуты.
Время выполнения (абсолютное) для любого кол-ва процессоров: t1 + t2 = 2 минуты.
Затраченное машинное время (для любого кол-ва процессоров) = t1 + t2 = 2 минуты.

Ускорение: ((1+1)/2)/((1+1)/2)=1

Аналогично - две абсолютно независимые задача (полное распараллеливание).

Узлов в графе задач - два.
Время выполнения (абсолютное) для одного процессора: t1 + t2 = 2 минуты.
Время выполнения (абсолютное) для 2 и более процессоров: = 1 минуты.
Затраченное машинное время (для любого кол-ва процессоров) = t1 + t2 = 2 минуты.

Ускорение: ((1+1)/2)/((1+1)/2)=1

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

Сергей Васкецов BelyКроме того, хочу заметить, что ваше "ускорение" имеет практический смысл только для подсчета издержек на переключение задач.
Ничего подобного. Это важнейшая характеристика, которая показывает как качество самого алгоритма распараллеливания задачи, так и позволяет экстраполировать оценку абсолютного времени выполнения в случае увеличения количества узлов при сохранении алгоритма и прочих условий.Алгоритм распараллеливания - он-то здесь каким боком?
Если у меня 10 задач по 1 минуте - как их не расставляй по процессорам, как они не завись друг от друга - 10 минут процессорного времени они займут.
Ни меньше - ни больше.

И еще раз повторюсь - для абсолютного времени - это не так.

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


Сергей ВаскецовТак что я бы не был столь категоричен. Не всегда сделать быстрее будет выгоднее.Если не брать в расчет "открытия опередившие время", то быстрее = выгоднее.
Это можно считать аксиомой.

Сергей ВаскецовПо прежнему предлагаю Вам придумать ситуацию, когда 40 процессоров выполнят при одном и том же алгоритме задачу более чем в 2 раза быстрее, чем 20 тех же одинаковых процессоров (чтобы ускорение было больше 1), причем хитрость не в самом алгоритме, то есть, будем считать, что он распараллеливается как угодно оптимально для любой схемы. А то меня не покидает ощущение, что мы с Вами разговариваем на разных языках.Меня тоже не покидает ощущение, что на разных языках говорим...

А пример простой.
40 независимых задач по 1 минуте.
40 процессоров выполнят их все за 1 минуту (будет готов результат по всем 40 задачам).
20 процессоров - выполнят 40 этих же задач за 2 минуты.

Сергей ВаскецовВнимательнее. Ускорение будет равно 1 (так как 40*T(40)/20*T(20)=1), так что ответ неверен (требуется найти ситуацию, чтобы ускорение было БОЛЬШЕ 1). Потому и все, что Вы написали выше, я опустил и не цитировал. Я уже подсказывал, что простых примеров Вам не удастся придумать.Если честно - я не знаю откуда вы взяли этот термин "ускорения".
Можете привести ссылку на какю-нибудь литературу где оно есть?
Мне физический смысл этой величины - вобще не понятен.

Ну, пусть оно равно 1 - это хорошо или плохо?
Оно вобще ПРО ЧТО?

пока писал ответ - появилось следующее сообщение.
Сергей ВаскецовЭто неверно. Время ожидания (простоя) также необходимо учитывать, а не чистое время работы процессора над задачей.Получается, что время о котором вы говорите - это (АБСОЛЮТНОЕ время для выполнения всех задач) * (кол-во процессоров).
Тогда все становится понятно, с точки зрения вашего "ускорения".

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

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

Сергей ВаскецовОбщие принципы те же самые. У ПМа так или иначе возникает задача, как максимально параллельно выполнять работу.Только паралельностью проект не убыстрить, потому что есть еще много чего кроме "распаралелить по максимуму".