одна идея касаемая с.п.о.
Например, p2p dc клиент: можно сходу выделить такие части, как интерфейс, модуль связи с сервером, модуль хеширования и составления списка своего контента. Интерфейс может быть как графическим так и консольным, как на Qt так и на GTK.
Можно также разбить задачу на более мелкие части, в идеале - чтоб реализацию осилил 1 человек или небольшая команда.
Теперь, допустим у нас есть веб проект с репозиторием, куда любой желающий может коммитить свой код, а так же предлагать своё т.з. на какой либо опенсорсный проект. На имеющиеся предопределенные интеррфейсы классов отдельно пишутся тесты, так что при коммите нового кода он сразу тестируется. У конечного пользователя еще больше выбора - использовать любую реализацию класса.
Ваше мнение?
А реализует пусть любой желающий. В сети есть целая куча энтузиастов, которые не знают, куда свой энтузиазм направить. Вот при таком подходе у новичка отточатся навыки программирования и работы в команде, плюс всё это будет не "для себя", а общественно полезный труд.
И еще естественно нужно иметь четко определенную систему управления всем этим делом. Например, кто-то что-то закоммитил и это прошло модерацию. далее - закомиченный сорс код тестируется после автоматического тестирования отдельными людьми и при положительном отклике Нтого количества тестеров признается годным.
Ок. Разделили проект на 10 частей. 3 части кто-то сделал, остальные 7 никому не интересны. Что делать? Продукта нет - одни части.
Далее. Пусть нашлось 10 человек. Пока один делал свою часть, заметил что в ТЗ были допущены логические ошибки (или ещё какие-нибудь). Он переделал интерфейс по своему, чтобы как-то работало. Всё, с остальными частями не соединяется. Что делать? А ведь скорее всего так будет со всеми частями.
а в случае с изменением интерфейса всё просто: чел просто публикует новую версию своего модуля а остальные кто зависит от него либо подгоняют свой код под новый интерфейс либо продолжают использовать старую версию того же модуля
Проблемы может и возникают, но сами собой не решаются. Нужен ответственный человек, который пинками и пряниками уговаривает команду работать, который привлекает новых людей и т.д.
Чтобы публиковать новую, надо чтобы была старая. А если ТЗ пишет любитель, то он не представляет, реализуемо ли то, что он напридумывал или нет, не представляет, насколько оно будет удобно для использования и т.д.
В общем, нужен координатор. Во вторых, ТЗ должно быть "живым", то есть переписываться, если есть необходимость. А самособирающаяся модель водопада - это утопия.
согласен. и желательно не один. вобще-то я априори рассматриваю ситуацию когда это условие выполнено и меня больше интересует вопрос организации распределённой разработки
Чтобы публиковать новую, надо чтобы была старая. А если ТЗ пишет любитель, то он не представляет, реализуемо ли то, что он напридумывал или нет, не представляет, насколько оно будет удобно для использования и т.д.
В общем, нужен координатор. Во вторых, ТЗ должно быть "живым", то есть переписываться, если есть необходимость. А самособирающаяся модель водопада - это утопия.
новичкам любителям нет смысла затевать проекты). такие проекты будут просто очень бысто самозагибаться и бог с ними, а насчёт самособирающейся модели водопада что-то не понял
Вот же:
http://ru.wikipedia.org/wiki/Модель_водопада
Или, более модная и современная альтернатива:
http://ru.wikipedia.org/wiki/Итеративная_разработка
Но автор темы говорит именно о Модели Водопада. Неуправляемой, но работающей.
эта работа может производиться абсолютно асинхронно и никаких итераций тут не надо
Как же не водопад? Как раз в водопаде не итерации, а этапы. Грубо говоря: написание ТЗ, проектирование, программирование, тестирование. И никаких возвратов к предыдущему этапу.
У автора темы ещё проще: написание безошибочного ТЗ, программирование.
Но если основа есть, то, конечно, можно допиливать, вносить улучшения... пока проект не превратится нечто хаотическое. Но для этого должен быть какой-то готовый продукт, который можно будет "улучшать".
Если я чем-то обидел, то извините, не хотел. Я лишь указываю на ошибки в теории. Возможно, на практике всё по другому.
То есть, чтобы был конструктивный разговор, нужен реальный проект, нужен переход к практике. Сделайте, посмотрим.