Структурированная разработка
К середине конца 70-х компьютерная индустрия уже перепробовала все описанные нами концепции и все равно оставалась несчастной. Цена поддержки программного обеспечения -- сохранения его функциональности перед лицом возможных изменений -- выливалась более чем в половину его общей стоимости, в некоторых случаях доходя до девяноста процентов !
Все соглашались, что эти издержки можно обычно отнести к неполному анализу программ или плохому замыслу разработчиков. Однако было очевидно, что что-то не так с самим структурированным программированием. Когда проекты появлялись с опозданием, некомплектными или некачественными, разработчики жаловались на то, что все предвидеть невозможно.
Ученые мужи прилагали все больше усилий к проекту. "В следующий раз мы все продумаем лучше".
К этому времени возникла новая философия, описанная в статье, названной "Структурированная разработка" [3]. Один из ее принципов приводится ниже:
Простота -- главный показатель, по которому рекомендуется выбирать среди альтернативных проектов для обеспечения снижения времени на отладку и модификацию. Уровень простоты может быть улучшен за счет разбиения системы на отдельные куски так, чтобы каждый из них мог рассматриваться, применяться, утверждаться и изменяться с минимальным влиянием на или изменениями в других частях системы.
Разбиение задачи на простые модули должно было облегчить написание, изменение и понимание программ.
Но на какой основе производить разбиение данного конкретного модуля ? Статья "Структурированная разработка" выделяет три фактора при проектирования модулей.
