Майерс. Надежность и стоимость ПО

Типичное распределение стоимости программного обеспечения:

• 17% - Проектирование;
• 8% - Программирование;
• 25% - Тестирование;
• 50% - Сопровождение.

Высокая стоимость программного обеспечения - во многом следствие низкой надёжности.

При увеличении производительности программиста (если измерять её только скоростью разработки и кодирования программы) стоимость существенно не уменьшается.

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

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

Программирование-производительность в разных странах

http://travnik.livejournal.com/10696.html

в Индии значительно чаще, чем в других старанах применяется парное программирование (и вообще, заметна тенденция вынесения «дорогих» с точки зрения использования людских ресурсов практик в страны с дешевой рабочей силой).
В Японии при очень высокой производительности кодирования (почти 500 тысяч строк в месяц на человека, тогда как в Европе 436 тысяч, в Индии - всего 209 тысяч) сохраняется высокое же качество кода (меньше 0,02 ошибок на тысячу – правда не сказано, что же это за плотность, если post-delivery, то с качеством в ведущих development компаниях России лучше, чем у японцев, если же имеется ввиду просто defect-density, тогда наше качество хуже японского на порядок). Подобные результаты достигаются высоким процентом реюза, и высоким же качеством описания reuse компонентов – ну тут в японцах никто и не сомневался, остается только выяснить стоимость японского человека-часа :)
Одним словом, если кто сомневается в победе Agile практик над waterfall’ом – читайте статью и свыкайтесь с мыслью, что придется переучиваться.