Единственное, что когда-либо действительно работал для меня был следовать принципы интерактивного дизайна. То есть, следуя этому рабочему потоку:
Определение сбора/определения целей> Пользовательские изображения/Проволочные рамки/Контрольные случаи> Графический дизайн/Разработка> Тестирование на основе тестовых случаев.
В принципе, вы должны иметь весь интерфейс, определенный на шаге 2, вместе с тестовыми примерами, которые определяют ожидаемые результаты для важных функций. Затем после (или в то время) вы создаете приложение, вы используете тестовые кейсы и проводные рамки для обеспечения того, чтобы он выглядел так, как планировалось.
Тестирование отдельных классов/функций может помочь вам в будущем, но большинство проектов измеряется качеством текущей версии, а не простотой, с которой вы можете исправить ошибки в текущей версии.
Что касается прогресса, то, как люди хотят, чтобы какая-то метрика вы могли измерить, это скажет вам, если проект слишком долго или слишком быстро, на самом деле его нет. Вещи, как правило, занимают столько, сколько им нужно, если вы попытаетесь сократить это время, конечный продукт не так хорош. Однако угроза надвигающегося срока является мощным мотиватором. Это тонкий баланс.
Я действительно никогда не находил никаких инструментов, которые в конечном итоге способствовали лучшему программному обеспечению, по крайней мере, до уровня качества измерений. Существует множество инструментов для того, чтобы занять меньше времени, чтобы достичь цели, но что касается оценки успеха этой цели, ничто не сравнится с предшествующим игровым кадром/тестовым документом и послеочередной оценкой того, насколько они совпадение.
Никогда не позволяйте никому говорить, что вы не можете проектировать весь проект очень подробно без кода. Если вы этого не сделаете, вы ОБЩИНЫ.
Вы можете только измерить размер, масштаб проекта с помощью LOC и потратить время, а не качество. – 2010-12-01 12:56:17
Я убежден, что нет другой надежной метрики, отличной от WPM (WTF в минуту). LoC плохо, потому что меньшее количество строк часто означает лучший код, функциональные изменения различаются по размеру, поэтому в качестве эталонного кадра нет постоянной, а затраченное время ненадежно, потому что хорошие программисты кодируют намного быстрее (коэффициент в 100 раз быстрее), чем плохой программистов, добавляя меньше ошибок и записывая (гораздо меньше) код. Однако вы можете почувствовать качество, проверив, сколько времени разработчики потратили на функцию по сравнению с тем, что они оценили. – dbemerlin 2010-12-01 13:02:57