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

Последние два вида работ дают очень малую долю:

[x]. Первый - это улучшение эффективности; похоже, предполагается, что когда система работает, менеджеры проекта и программисты неохотно прерывают ее работу с целью улучшения производительности, предпочитая не трогать довольно хорошую систему. (При рассмотрении принципа "сначала сделай ее хорошо, а потом сделай ее быстрой" многие проекты, возможно, вполне довольствуются первым шагом.)

[x]. Небольшие средства тратятся и на "переход к новой аппаратной среде". Из-за отсутствия более детальных данных можно высказать лишь некоторое предположение. Все системы относятся к двум крайним случаям, промежуточные варианты практически отсутствуют. В первом случае системы изначально строятся как переносимые, и потому для них этот вид затрат невелик. Другие настолько тесно привязаны к своей первоначальной платформе и перенос был бы так труден, что разработчики даже не пытаются делать что-то в этом направлении.

Ключевые концепции

[x]. Целью программной инженерии является нахождение путей построения ПО высокого качества.

[x]. Качество ПО лучше всего видится как компромисс между целым рядом различных целей, а не как единый фактор.