В ТЗ нет. Но вы должны выстроить рабочий процесс. Который состоит из опроса конечных пользователей, внесения изменений в ТЗ, кодирования и фиксации в системе контроля версий, фиксации работы в багтрекере (сколько времени ушло, что за номер бага, фичи, раздел в ТЗ) и как результат отчета из багтрекинга акт приемки.
Polish_Flamethrower, смотрите общение с сервером, все заголовки подделывайте, запрашивайте все файлы, выполняйте в виртуальной машине все скрипты. Это очень жестко и не даст вам уверенности
Johnny_Cash,
1. ТЗ основа основ.
2. Система контроля версий.
3. Багтрекер
4. Акт приема (и оплата)
То есть цепочка изменений идет через 4 этих пункта.
По идее любая контора получившая на руки ТЗ, в состоянии развернуть решение и стартовать процесс доработки. Либо что то не правильно.
Adamos, это не относится к языку. Любой нормальный разработчик вырабатывает систему для быстрого воспоминания своих проектов. Своеобразный мнемокод. Формализовать это сложно, особенно для команд с разными стилями разработки
Adamos, С чего вы взяли?
Это моя личная система быстрого воспоминания проекта. А так код абсолютно прозрачен. Только вы на то что бы понять потратите день или 2 - 3 недели, в зависимости от размера.
Adamos, По моему опыты создает, несмотря на то что я каждый шаг фиксирую. Это кстати и хорошо, через какое то время обращаются и я через свою базу смотрю что делал.
Adamos, Это и есть решение. SharePoint это довольно известное решение. С огромным коммунити и решениями на практически каждую задачу, правда от этого не легче
2 https://training.github.com/downloads/ru/github-gi...
3 https://www.redmine.org/
В ТЗ нет. Но вы должны выстроить рабочий процесс. Который состоит из опроса конечных пользователей, внесения изменений в ТЗ, кодирования и фиксации в системе контроля версий, фиксации работы в багтрекере (сколько времени ушло, что за номер бага, фичи, раздел в ТЗ) и как результат отчета из багтрекинга акт приемки.