Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы
Поэтому мы должны рассмотреть те направления, которые затрагивают саму сущность проблемы программирования — формулировку этих сложных концептуальных структур. К счастью, некоторые из этих направлений весьма многообещающи.
Покупать, а не создавать. Наиболее радикальное возможное решение при создании программ — вообще не создавать их.
С каждым днем это становится все легче, поскольку все большее число поставщиков предлагает все более многочисленные и лучшие программные продукты для немыслимого разнообразия приложений. Пока мы, инженеры-программисты, трудились над совершенствованием методологии производства, революция, произведенная персональными компьютерами, создала не один, а много массовых рынков программного обеспечения. В каждом газетном киоске выставлены ежемесячные журналы, в которых, отсортированные по типам машин, рекламируются и рецензируются десятки продуктов по ценам от нескольких долларов до нескольких сотен долларов. Более специализированные издания предлагают очень мощные продукты для рабочих станций и других рынков Unix. Даже инструменты и среды программирования могут быть куплены в коробочном виде. Я где-то предложил базар для отдельных модулей.
Любой такой продукт дешевле купить, чем создавать заново. Даже при цене 100 000 долларов купленный продукт стоит примерно столько, сколько годовое содержание программиста. И поставка немедленная! Немедленная, по крайней мере, для реально существующих продуктов, проспект которых разработчик может послать счастливому пользователю. Более того, такие продукты обычно гораздо лучше документированы и несколько лучше сопровождаются, чем доморощенные программы.
Развитие массового рынка является, по моему мнению, наиболее глубокой долгосрочной тенденцией программной инженерии. Стоимость программного продукта всегда определялась стоимостью разработки, а не тиражирования. Разделив эту стоимость даже на нескольких пользователей, мы коренным образом снижаем цену на одного пользователя. Взглянув на это с другой стороны, мы видим, что использование п копий программной системы фактически умножает на п производительность его разработчиков. Это рост производительности отрасли и всей страны.
Главным вопросом, конечно, является производительность. Смогу ли я использовать имеющийся коробочный продукт для решения своих задач? Здесь случилась удивительная вещь. В 50-х и 60-х годах одно исследование за другим показывало, что пользователи не хотят использовать коробочные пакеты для расчета зарплаты, управления складом, учета дебиторов по расчетам и т.д. Требования были слишком специальными, отклонения от случая к случаю слишком большими. В 80-х годах мы обнаруживаем большой спрос на такие пакеты и широкое их использование. Что изменилось?
Только не пакеты. Они стали несколько более общими и лучше настраиваются, чем раньше, но не намного. И не область их применения. В конце концов, сегодня потребности бизнеса и науки более разнообразны и сложны, чем 20 лет назад.
Резко изменилось соотношение стоимости компьютеров и программ. Тот, кто в 1960 году покупал машину за 2 миллиона долларов, считал, что может позволить себе потратить еще 250 000 долларов на заказную программу расчета зарплаты, которая легко и без ущерба вписалась бы во враждебную компьютерам социальную среду. Те, кто сегодня покупают машину для офиса за 50 000 долларов, не могут, понятно, позволить себе заказные программы расчета зарплаты, поэтому они приспосабливают свои процедуры расчета зарплаты к имеющимся пакетам. Компьютеры сейчас столь обычны, если не столь любимы, что адаптация воспринимается как обычное дело.
Есть яркие исключения из моего утверждения о том, что обобщенность программных пакетов за последние годы мало изменилась: электронные таблицы и простые системы баз данных. Эти мощные инструменты, столь очевидные задним умом и так поздно появившиеся, имеют бесчисленное множество применений, в том числе, весьма необычные. Есть масса статей и даже книг о том, как с помощью электронной таблицы решать неожиданные задачи. Большое число задач, для которых раньше были бы написаны заказные программы на Cobol или Report Program Generator, теперь шаблонно решается с помощью этих инструментов.
Многие пользователи изо дня в день применяют свои компьютеры для разных приложений, никогда не написав ни одной программы. На практике многие из этих пользователей и не могут писать для своих машин новые программы, но тем не менее приверженцы решению возникающих задач с их помощью.
Я считаю, что сегодня для многих организаций самая правильная политика для повышения производительности разработки программного обеспечения — это установить своим не имеющим компьютерных знаний работникам умственного труда компьютеры и хорошие общие программы для обработки текстов, рисования, работы с файлами и электронными таблицами и отпустить их в вольное плавание. Такая же политика в отношении распространенных математических и статистических пакетов, а также некоторых навыков программирования подойдет сотням ученых, работающих в лабораториях.
Уточнение требований и быстрое макетирование. Самая трудная отдельная задача в разработке программной системы — это точно решить, что разрабатывать. Ни одна другая задача работы над концепциями не является столь трудной, как разработка подробных технических требований, включая все интерфейсы пользователей, машинные интерфейсы и интерфейсы к другим программным системам. Ни одна другая часть работы не наносит такого ущерба готовой системе, если сделана неправильно. Ни одна другая часть не исправляется позднее с бульшим трудом.
Поэтому наиболее важной функцией, осуществляемой разработчиками для своих клиентов, является повторяющееся получение и уточнение требований к продукту. Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумывались над задачей настолько детально, как это нужно указать в спецификации. Даже простой ответ — «сделайте так, чтобы новая программная система работала так, как наша старая ручная система обработки информации» — оказывается в действительности слишком упрощенным. Клиенты никогда не хотят этого в точности. Более того, сложные программные системы действуют, движутся, работают. Динамику этого действия трудно себе представить. Поэтому при планировании любых действий необходимо оставить резерв для многократного взаимодействия между клиентом и проектировщиком при описании системы.
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют.
Поэтому одним из наиболее многообещающих современных направлений в технологии, причем обращенных к сущности, а не к акциденциям проблем программирования, является разработка подходов и инструментов для быстрого создания макетов систем как части итеративного процесса разработки спецификаций.
Макет программной системы моделирует главные интерфейсы и выполняет основные функции предполагаемой системы, при этом не обязательно будучи связан теми же ограничениями быстродействия компьютера, размера или стоимости. Обычно макеты выполняют основные задачи системы, но не пытаются обрабатывать исключительные ситуации, правильно реагировать на ввод недопустимых данных, корректно прерывать работу и т.д. Назначение макета — показать, как воплощается выбранная концептуальная структура, чтобы клиент мог проверить ее пригодность к использованию и непротиворечивость.
Сегодня многие процедуры приобретения программного обеспечения основываются на предположении, что можно заранее задать технические требования для желаемой системы, рассмотреть предложения разработчиков, получить разработанную систему и установить ее. Я думаю, что такое предположение в корне неверно, и из-за этой ошибки проистекают многие проблемы при приобретении программ, поскольку эти проблемы нельзя устранить без пересмотра основ, для которого требуется интерактивная разработка и спецификации макетов и продуктов.
Пошаговая обработка: наращивать программу, а не строить сразу. Я до сих пор помню испытанный в 1958 году удар, когда впервые услышал, как мой друг говорил о строительстве (building) программ в противоположность написанию (writing). В мгновение он расширил все мое представление о процессе программирования. Применение метафоры было сильным и точным. Сегодня мы понимаем, что сходство существует между созданием программы и другими строительными процессами, и свободно используем другие элементы метафоры, такие как спецификации (specifications), сборка компонентов (assembly of components), леса (scaffolding).
