Люди! Подскажите мне...
Какие есть способы записи изменений в программе (т.е. того, что изменено и почему изменено), записей обнаруженных багов.
Вообще, насколько подробно эти вещи документируются в разных методологиях и какие программные средства для этого используются.
Понятное дело, что одним комментарием к ревизии в SVN дело, наверное, не ограничивается...
Интересует как теория, так и впечатления от применения этой теории.
Кто-нибудь составляет план тестирования по уже готовому коду, что бы проверить соответствие ожиданий и реальности именно по коду (а не по ТЗ)?
Как нормальные люди составляют расписание разработки проекта. Т.е., представим себе, у нас есть задание на относительно сложную систему. Скажем, проектирования каких-нибудь сооружений (упппс). Допустим, что мы хотим для начала сделать небольшую систему проектирования отдельного узла конструкции и его продавать. Т.е. сначала хотим спроектировать и закодировать более простую систему, не очень-то думая о большой.
Дальше идёт усложнение системы: отрисовка узла смещается в архитектуре системы с позиции системы визуализации в позицию только одного класса отрисовываемых узлов, над ней изменяется визуальная система. То же происходит и со всеми остальными частями системы. Т.е. то, что раньше было подсистемой отходит на более низкий уровень и немного видоизменяется.
Вопрос: как в начале разработки описать, что мы собираемся сначала сделать такую-то структуру классов, а затем видоизменить её в другую структуру классов в такой-то последовательности при этом тестируя сначала то-то и то-то, а потом то-то и то-то? Ээ, предполагается, что не словами, а если и словами, то как-то структурировано, что бы можно было понять общий замысел архитектора.
03.05.07 10:17: Перенесено из 'Философия программирования'