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

Соответственно - вряд ли возможно что-то кроме переделки по шагам, метода последовательных изменений. Переписать модули по одному, если при этом не подразумевается смена инструмента - задача реальная.

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

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

GoldDragonЯ уверен что ты скорее всего уже автоматом можешь определить какой модуль более важен или нужен, какой стоит улучшать какой нет.
Я - не уверен :) Не думаю, что хоть у кого-то есть опыт таких масштабов, чтобы столь важные задачи можно было решать, не думая. У меня есть опыт такой вот пошаговой полной замены, но на достаточно скромном по размерам проекте.

На какие критерии данного модуля нужно обратить внимание?
Пожалуй, примерно так:

0. Текущие зияющие дыры, которые необходимо срочно закрыть.

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

2. Отчуждаемость; насколько четко определен и формализован интерфейс модуля, насколько тесно он связан с другими. Попросту говоря, насколько легко переделать этот модуль, не ломая остальную программу.

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

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

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

Обязательно ли брать новых людей или достаточно чтобы когда будет окно в заданиях развивать новую версию конкретного модуля?
Зависит от людей. Если они хотят и могут работать так, как Вы потребуете - что плохого в том, чтобы на них и опираться?

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

Как правильно спланировать улучшщение 1-го модуля, чтобы это не затронуло старые?
Собственно основной принцип модульного программирования - пока выдерживается оговоренный интерфейс взаимодействия, плевать, как меняется реализация.

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

Другой важный аспект - прозрачная реализация новой технологической базы. Новая технология стопроцентно повлечет необходимость реализации каких-либо новых базовых классов, функций ядра итп. Такие вещи, понятно, нужно делать как минимум не конфликтующими со старыми, а по возможности - так, чтобы старый код заработал с использованием нового API. Опять-таки пример из дельфы - допустим, старое MDI-приложение хочется переделать на интерфейс с закладками (pagecontrol). Для этого я бы действовал примерно так: определил бы тривиальный базовый класс окна, настроив его под MDI; унаследовал бы от этого класса ранее реализованные формы; когда не осталось бы неохваченных форм, переделал бы методы базового класса так, чтобы они вместо MDI создавали закладку и клали окно на нее. Главное здесь - постараться не спеша привести все к единому образцу; не требовать "быстро и синхронно поменять кучу всего везде".

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

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

GoldDragonВ Delphi немного другая ситуация, как мне кажется. Я не могу взять и поменять одно окно, при этом чтобы другие остались как и раньше (как бы мне этого хотелось). Если менять на новые технологии, то менять всё или ничего (VB6 to Dot.Net)
Смена инструмента - безусловно, более тяжелый процесс, но почти уверен, что и в этом случае можно что-то придумывать. Тут больше вопрос именно владения инструментом; ни по VB, ни по VB.NET, к сожалению, ничего сказать не смогу.

GoldDragonМне бы очень хотелось, чтобы меня взяли руководителем проекта, но к сожелению это не так. Меня просто попросили, как более квалифицированного программиста, посмотреть, что можно сделать.
Тогда имейте в виду - говоря о "можно изменить", не скромничайте насчет необходимых полномочий. Тут надо смотреть по ситуации, но грубо говоря если будет серьезная модификация, и Вы - единственный, кто в этом разбирается и кто будет нести немалую долю ответственности за результат, нужен соответствующий статус. Говорить "ну ребята, ну давайте ну начнем делать хорошо" можно долго и безрезультатно.

GoldDragon softwarerPS. Я бы постарался не обидеть ребят. Ни в коем случае - вы сделали фуфло, давайте делать так.
На всякий случай подчеркну, что эта цитата приписана мне по ошибке.