Методика разработки

Методика разработки это по сути то, с чего начинается любой проект. В данном случае, я не имею в виду процессы, типа RUP или XP или еще какой P, а скорее конфигурацию проекта.
Цель этого текста не дать какой-то рецепт, а скорее структурировать собственные знания.
Да, и следует иметь в виду что все это написано в контексте разработки web-приложений на java.
Каждый раз начиная новый проект приходится отвечать на вопросы:

1. Будет ли это одномодульный или многомодульный проект?
2. Каким образом будет осуществляться взаимодействие между участниками?
3. Какова область ответственности каждого участника?
4. Какие средства стоит использовать для сборки, тестирования и прочего?
   

И при этом всякий раз происходят внутренние колебания, сомнения, возникают дискуссии внутри команды и т.д. Вообще-то это нормальный процесс, но со временем возникает ощущение что на самом деле существует довольно-таки ограниченный выбор решений (или шаблонов, если угодно) из которого можно выбирать подходящее для конкретного проекта и дополнять/упрощать его, если уж проект такой уникальный.
Вот собственно я и хочу попробовать набросать несколько таких шаблонов, чтобы облегчить себе и коллегам такой выбор.

"Мелкое приложение"
Как следует из названия шаблон предназначен для небольших приложений, как правило, разрабатываемых одним автором. Как определить масштаб приложения каждый выбирает индивидуально, конечно. Я бы определил по числу используемых сущностей, в данном случае, не более 5-6. Что характерно, при таком определении количество пользователей (а значит и нагрузка) и/или размер базы могут быть весьма и весьма не маленькими.
1. Модульность - проект одномодульный во избежание излишнего усложнения, тем более для одного разработчика. Понятие модуля, обычно, соответствует понятию проект в средах разработки. Во всяком случае, для Eclipse это тождественные понятия. Но даже в случае коллективной работы сложностей не должно быть, если:
2. Средства коллективной разработки - subversion. Конечно и вопрос звучит несколько шире и существуют и другие системы контроля версий, помимо subversion, но в данном контексте, думаю, этого достаточно.
3. Область ответственности - т.к. разработчик скорее всего один, то он несет ответственность за приложение. Если для каких-то целей привлекаются дополнительные участники, например, web-дизайнер, то в этом случае четко должна быть определена их зона ответственности. Для дизайнера соответственно это будет внешнее оформление приложения: шаблоны, графические элементы и пр.
4. Вспомогательные средства
4.1 Сборка - в данном случае уместно использовать Аnt, как относительно простое, надежное и независимое от IDE средство.
4.2 Тестирование - JUnit, а также его различные расширения в зависимости от особенностей проекта и требованиям к качеству.
В общем-то и все. Можно использовать еще много разных средств для улучшения качества кода, поиска ошибок, но, как мне кажется достаточный уровень для разработки достигнут.

Ждем вдохновения и новые шаблоны проектов.