А как вообще документируют историю исправлений и план разр.?
От: FDSC Россия consp11.github.io блог
Дата: 01.05.07 17:13
Оценка:
Люди! Подскажите мне...
Какие есть способы записи изменений в программе (т.е. того, что изменено и почему изменено), записей обнаруженных багов.

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

Интересует как теория, так и впечатления от применения этой теории.



Кто-нибудь составляет план тестирования по уже готовому коду, что бы проверить соответствие ожиданий и реальности именно по коду (а не по ТЗ)?



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

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

Вопрос: как в начале разработки описать, что мы собираемся сначала сделать такую-то структуру классов, а затем видоизменить её в другую структуру классов в такой-то последовательности при этом тестируя сначала то-то и то-то, а потом то-то и то-то? Ээ, предполагается, что не словами, а если и словами, то как-то структурировано, что бы можно было понять общий замысел архитектора.



03.05.07 10:17: Перенесено из 'Философия программирования'
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.