Страница:
издания предлагают очень мощные продукты для рабочих станций и других рынков
Unix. Даже инструменты и среды программирования могут быть куплены в
коробочном виде. Я где-то предложил базар для отдельных модулей.
Любой такой продукт дешевле купить, чем создавать заново. Даже при цене
100 000 долларов купленный продукт стоит примерно столько, сколько годовое
содержание программиста. И поставка немедленная! Немедленная, по крайней
мере, для реально существующих продуктов, проспект которых разработчик может
послать счастливому пользователю. Более того, такие продукты обычно гораздо
лучше документированы и несколько лучше сопровождаются, чем доморощенные
программы.
Развитие массового рынка является, по моему мнению, наиболее глубокой
долгосрочной тенденцией программной инженерии. Стоимость программного
продукта всегда определялась стоимостью разработки, а не тиражирования.
Разделив эту стоимость даже на нескольких пользователей, мы коренным образом
снижаем цену на одного пользователя. Взглянув на это с другой стороны, мы
видим, что использование n копий программной системы фактически умножает на
n производительность его разработчиков. Это рост производительности отрасли
и всей страны.
Главным вопросом, конечно, является производительность. Смогу ли я
использовать имеющийся коробочный продукт для решения своих задач? Здесь
случилась удивительная вещь. В 50-х и 60-х годах одно исследование за другим
показывало, что пользователи не хотят использовать коробочные пакеты для
расчета зарплаты, управления складом, учета дебиторов по расчетам и т.д.
Требования были слишком специальными, отклонения от случая к случаю слишком
большими. В 80-х годах мы обнаруживаем большой спрос на такие пакеты и
широкое их использование. Что изменилось?
Только не пакеты. Они стали несколько более общими и лучше
настраиваются, чем раньше, но не намного. И не область их применения. В
конце концов, сегодня потребности бизнеса и науки более разнообразны и
сложны, чем 20 лет назад.
Резко изменилось соотношение стоимости компьютеров и программ. Тот, кто
в 1960 году покупал машину за 2 миллиона долларов, считал, что может
позволить себе потратить еще 250 000 долларов на заказную программу расчета
зарплаты, которая легко и без ущерба вписалась бы во враждебную компьютерам
социальную среду. Те, кто сегодня покупают машину для офиса за 50 000
долларов, не могут, понятно, позволить себе заказные программы расчета
зарплаты, поэтому они приспосабливают свои процедуры расчета зарплаты к
имеющимся пакетам. Компьютеры сейчас столь обычны, если не столь любимы, что
адаптация воспринимается как обычное дело.
Есть яркие исключения из моего утверждения о том, что обобщенность
программных пакетов за последние годы мало изменилась: электронные таблицы и
простые системы баз данных. Эти мощные инструменты, столь очевидные задним
умом и так поздно появившиеся, имеют бесчисленное множество применений, в
том числе, весьма необычные. Есть масса статей и даже книг о том, как с
помощью электронной таблицы решать неожиданные задачи. Большое число задач,
для которых раньше были бы написаны заказные программы на Cobol или Report
Program Generator, теперь шаблонно решается с помощью этих инструментов.
Многие пользователи изо дня в день применяют свои компьютеры для разных
приложений, никогда не написав ни одной программы. На практике многие из
этих пользователей и не могут писать для своих машин новые программы, но тем
не менее приверженцы решению возникающих задач с их помощью.
Я считаю, что сегодня для многих организаций самая правильная политика
для повышения производительности разработки программного обеспечения - это
установить своим не имеющим компьютерных знаний работникам умственного труда
компьютеры и хорошие общие программы для обработки текстов, рисования,
работы с файлами и электронными таблицами и отпустить их в вольное плавание.
Такая же политика в отношении распространенных математических и
статистических пакетов, а также некоторых навыков программирования подойдет
сотням ученых, работающих в лабораториях.
Уточнение требований и быстрое макетирование. Самая трудная отдельная
задача в разработке программной системы - это точно решить, что
разрабатывать. Ни одна другая задача работы над концепциями не является
столь трудной, как разработка подробных технических требований, включая все
интерфейсы пользователей, машинные интерфейсы и интерфейсы к другим
программным системам. Ни одна другая часть работы не наносит такого ущерба
готовой системе, если сделана неправильно. Ни одна другая часть не
исправляется позднее с бoльшим трудом.
Поэтому наиболее важной функцией, осуществляемой разработчиками для
своих клиентов, является повторяющееся получение и уточнение требований к
продукту. Правда заключается в том, что клиенты не знают, чего хотят. Обычно
они не знают, на какие вопросы нужно дать ответ, и почти никогда не
задумывались над задачей настолько детально, как это нужно указать в
спецификации. Даже простой ответ - "сделайте так, чтобы новая программная
система работала так, как наша старая ручная система обработки информации" -
оказывается в действительности слишком упрощенным. Клиенты никогда не хотят
этого в точности. Более того, сложные программные системы действуют,
движутся, работают. Динамику этого действия трудно себе представить. Поэтому
при планировании любых действий необходимо оставить резерв для многократного
взаимодействия между клиентом и проектировщиком при описании системы.
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе
с инженерами-программистами, не в состоянии указать полно, строго и
корректно точные требования к современному программному продукту, прежде чем
будут созданы и опробованы какие-либо версии продукта, спецификации к
которому они составляют.
Поэтому одним из наиболее многообещающих современных направлений в
технологии, причем обращенных к сущности, а не к акциденциям проблем
программирования, является разработка подходов и инструментов для быстрого
создания макетов систем как части итеративного процесса разработки
спецификаций.
Макет программной системы моделирует главные интерфейсы и выполняет
основные функции предполагаемой системы, при этом не обязательно будучи
связан теми же ограничениями быстродействия компьютера, размера или
стоимости. Обычно макеты выполняют основные задачи системы, но не пытаются
обрабатывать исключительные ситуации, правильно реагировать на ввод
недопустимых данных, корректно прерывать работу и т.д. Назначение макета -
показать, как воплощается выбранная концептуальная структура, чтобы клиент
мог проверить ее пригодность к использованию и непротиворечивость.
Сегодня многие процедуры приобретения программного обеспечения
основываются на предположении, что можно заранее задать технические
требования для желаемой системы, рассмотреть предложения разработчиков,
получить разработанную систему и установить ее. Я думаю, что такое
предположение в корне неверно, и из-за этой ошибки проистекают многие
проблемы при приобретении программ, поскольку эти проблемы нельзя устранить
без пересмотра основ, для которого требуется интерактивная разработка и
спецификации макетов и продуктов.
Пошаговая обработка: наращивать программу, а не строить сразу. Я до сих
пор помню испытанный в 1958 году удар, когда впервые услышал, как мой друг
говорил о строительстве (building) программ в противоположность написанию
(writing). В мгновение он расширил все мое представление о процессе
программирования. Применение метафоры было сильным и точным. Сегодня мы
понимаем, что сходство существует между созданием программы и другими
строительными процессами, и свободно используем другие элементы метафоры,
такие как спецификации (specifications), сборка компонентов (assembly of
components), леса (scaffolding).
Метафора строительства пережила свое время. Пора снова вносить
изменения. Если, как я считаю, создаваемые сегодня концептуальные структуры
слишком сложны, чтобы их можно было точно специфицировать заранее, и слишком
сложны, чтобы строить без ошибок, тогда нужен радикально иной подход.
Обратимся к природе и рассмотрим сложность живых созданий, а не
безжизненных творений человека. Там мы обнаруживаем конструкции, сложность
которых вселяет в нас ужас. Один только мозг настолько сложен, что
невозможно составить его схему. Его мощь невозможно повторить, он богат
своеобразием, способен к самосохранению и самообновлению. Секрет в том, что
мозг растет, а не строится.
Так же должны создаваться наши программные системы. Несколько лет назад
Харлан Миллз предложил наращивать программные системы путем пошаговой
разработки.11 Это значит, что сначала систему надо заставить выполняться,
даже если при этом она не делает ничего полезного, кроме вызова некоторого
числа фиктивных подпрограмм. Затем она понемногу обрастает мясом, причем
подпрограммы, в свою очередь, разрабатываются сначала как вызовы пустых
фиктивных подпрограмм, находящихся на уровень ниже.
Настаивая на применении этой технологии разработчиками проектов на моих
лабораторных занятиях по программной инженерии, я стал свидетелем
поразительных результатов. За последнее десятилетие ничто другое не оказало
столь сильного влияния на мою собственную работу и ее эффективность. Этот
подход предполагает нисходящее проектирование, поскольку это - нисходящее
наращивание программы. Он позволяет легко отслеживать работу в обратном
направлении. Он предоставляет возможность раннего создания макетов. Каждая
новая функция или возможность работы с более сложными данными или условиями
органически вырастают на того, что уже имеется.
Воздействие на моральный дух ошеломительное. Когда есть хотя бы простая
работающая система, возрастает энтузиазм. Энергия удваивается, когда на
экране появляется картинка из новой графической программной системы, даже
если это всего лишь прямоугольник. И на каждой стадии процесса разработки
существует работающая система. Я считаю, что за одинаковые сроки команда
может нарастить значительно более сложный объект, чем построить.
В больших проектах можно ощутить такие же выгоды, как и в моих
маленьких.12
Выдающиеся проектировщики. Главная проблема совершенствования искусства
программирования заключена, как всегда, в людях.
Мы можем добиваться хороших проектов, следуя хорошим, а не плохим
практическим приемам. Хорошим приемам можно обучать. Программисты
принадлежат к наиболее интеллектуальной части общества, следовательно, они в
состоянии изучать хорошие приемы. Поэтому важнейшим направлением в
Соединенных Штатах является распространение хороших современных приемов.
Новые курсы, новые издания, новые организации, такие как Институт инженеров-
программистов (Software Engineering Institute) - все это вызвано к жизни
стремлением повысить уровень наших практических приемов. Это совершенно
правильно.
Тем не менее, я считаю, что мы не сможем подняться еще на одну
ступеньку выше, действуя в этом направлении. Выбор правильного метода
проектирования определяет различия между плохим и хорошим концептуальным
проектом, но не между хорошим и выдающимся. Выдающиеся проекты создаются
выдающимися проектировщиками. Создание программ является творческим
процессом. Крепкая методология может придать силу и освободить творческий
ум, но она не может воспламенить или вдохновить того, кто занят нудной
работой.
И разница немалая - это как Сальери и Моцарт. Одно исследование за
другим показывают, что лучшие проектировщики создают структуры, которые
быстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями.
Различия между выдающимся и средним достигают порядка величины.
Нетрудно проследить, что ряд хороших и полезных программных систем
проектировался комиссиями и создавался с помощью проектов, состоявших из
многих частей. Но программные системы, вызвавшие восхищение страстных
поклонников, являются продуктом одного или небольшого числа выдающихся
проектировщиков. Посмотрите на Unix, APL, Pascal, интерфейс Smalltalk и даже
Fortran - с одной стороны, и Cobol, PL/I, Algol, MVS/370 и MS-DOS - с другой
(рис. 16.1).
Рис. 16.1 Имеются ли у этих продуктов страстные поклонники?
Поэтому, высоко ценя нынешние программы передачи технологий и развития
обучения, я считаю, что наиболее важной программой, которую мы можем
предпринять, является развитие способов воспитания выдающихся
проектировщиков.
Ни одна занятая в программировании организация не может игнорировать
эту проблему. Хороших менеджеров, как бы мало их ни было, не меньше, чем
хороших проектировщиков. Как выдающиеся проектировщики, так и выдающиеся
менеджеры встречаются редко. В большинстве организаций значительные усилия
тратятся на поиска и выращивание подающих надежды менеджеров. Я не слышал,
чтобы кто- либо тратил такие же усилия на поиски и развитие выдающихся
проектировщиков, от которых, в конечном счете, зависит техническое
превосходство продуктов.
Первое мое предложение состоит в том, чтобы каждая занятая в
программировании организация определила для себя и провозгласила, что
выдающиеся проектировщики имеют для ее успеха такое же большое значение, как
и выдающиеся менеджеры, и что они могут рассчитывать на такие же заботу и
вознаграждение. Не только зарплата, но и атрибуты положения - размеры офиса,
мебель, техническое оборудование, командировочные фонды, обеспеченность
сотрудниками - должны быть полностью равнозначны.
Как растить выдающихся проектировщиков? Место не позволяет обсуждать
это пространно, но вот некоторые очевидные шаги:
- Систематически и как можно раньше выявлять первоклассных
проектировщиков. Лучшие - не всегда самые опытные.
- Назначить наставника, ответственного за рост перспективного
проектировщика и тщательно следить за его карьерой.
- Разработать и осуществлять план служебного роста для каждого
перспективного проектировщика, включающий тщательно продуманное обучение у
передовых проектировщиков, периоды дополнительного формального обучения,
краткосрочные курсы, перемежающиеся с самостоятельным проектированием и
назначением на руководящие технические должности.
- Обеспечить возможности для взаимодействия и взаимного стимулирования
растущих проектировщиков.
У всякой пули - свое
предназначение.
ВИЛЬГЕЛЬМ III ОРАНСКИЙ
Кто хочет увидеть образец совершенства,
Тот мечтает о том, чего никогда не было,
нет и не будет.
АЛЕКСАНДР ПОП, "О КРИТИКЕ"
Об оборотнях и прочих мифических ужасах
"Серебряной пули нет: сущность и акциденция в программной инженерии"
(глава 16 данной книги) первоначально была заказным докладом для конференции
IFIP (Международной федерации по обработки информации) 1986 года в Дублине и
была опубликована в ее трудах.1 Журнал "Computer" перепечатал ее под
обложкой в готическом стиле, иллюстрируя кадрами из фильмов, таких как
"Вервольф из Лондона",2 и снабдив боковым полем "Убить вервольфа" с
изложением современной легенды о том, что справиться с ним можно только с
помощью серебряной пули. До публикации я не знал об иллюстрациях, и для меня
было неожиданностью, что серьезная техническая статья была так красочно
издана.
Однако редакторы "Computer" знали свое дело и достигли желаемого
результата: похоже, что статью прочли многие. Поэтому я подобрал для той
главы еще одну картинку с оборотнем - старинное изображение почти забавного
создания. Надеюсь, что эта менее яркая картинка окажет такое же полезное
действие.
Серебряная пуля все-таки есть - ВОТ ОНА!
"Серебряной пули нет" утверждает и доказывает, что в течение
десятилетия (с момента публикации статьи в 1986 году) ни одна разработка в
области техники программного обеспечения не позволит повысить
производительность труда в программировании на порядок. Из этого десятилетия
прошло уже девять лет, и можно посмотреть, насколько сбывается предсказание.
В то время как "Мифический человеко-месяц" породил частое цитирование и
мало споров, статья "Серебряной пули нет" вызвала статьи с опровержениями и
письма в редакции журналов, поток которых не прекратился и по сей день.3
Чаще всего критикуется главное утверждение о том, что волшебного решения
нет, и мое ясно выраженное мнение о том, что его и быть не может.
Большинство соглашается с основной частью моих аргументов в "СПН", но затем
заявляет, что в действительности серебряная пуля для программного зверя
существует, и изобрел ее автор. Перечитывая сегодня ранние отклики, не могу
не отметить, что патентованные средства, столь энергично предлагавшиеся в
1986 и 1987 годах, не возымели эффекта, на который претендовали.
Я обычно покупаю компьютеры и программы, проверяя их на "счастливом
обладателе", т.е. беседуя с вызывающими доверие людьми, заплатившими деньги
за продукт и пользующимися им с удовольствием. Аналогично, я с готовностью
поверю в материализацию серебряной пули, когда вызывающий доверие
независимый пользователь выступит вперед и скажет: "Я использовал эту
методологию, этот инструмент или продукт, и это позволило мне в десять раз
повысить производительность разработки программ".
Многие корреспонденты сделали верные поправки и разъяснения. Некоторые
проанализировали статью пункт за пунктом и привели возражения, за что я им
благодарен. В этой главе я хочу сообщить о сделанных поправках и ответить на
опровержения.
Неясное изложение влечет непонимание
Судя по некоторым откликам, мне не удалось четко изложить свои
аргументы.
Второстепенное свойство (accident). В резюме главы 16 я постарался со
всей возможной ясностью изложить основные аргументы "СПН". Некоторые,
однако, были смущены терминами второстепенное свойство (accident) и
несущественный, второстепенный (accidental), которые я использовал в старом
употреблении, восходящем к Аристотелю.4 Под accidental я не имел в виду
"случайный" или "относящийся к несчастному случаю", а скорее,
"несущественный", "побочный" (incidental) или "принадлежащий" (appurtinent).
Я не хочу порочить роль случайности при разработке программ. Вслед за
английским драматургом, автором детективов и теологом Дороти Сэйерс (Dorothy
Sayers) я рассматриваю всякую творческую деятельность, как состоящую из: а)
формулирования концептуальных конструкций, б) воплощения в реальном
материале и в) диалога с пользователем в реальной жизни.5 Та часть
построения программы, которую я назвал сущностью (essence), состоит из
умственной работы создания концепутальной конструкции, а та, которую я
назвал второстепенной (accident), есть процесс ее воплощения.
Выяснение истины. Мне кажется (хотя не все со мной согласны), что
верность центрального аргумента сводится к выяснению ответа на вопрос: какая
доля затрат связана с точным и упорядоченным представлением концептуальной
конструкции, а какая - с умственными усилиями по изготовлению этих
конструкций. Поиск и устранение ошибок попадают в тот или иной раздел в
зависимости от того, являются ли ошибки концептуальными (например, пропуск
какого-либо особого случая) или ошибками представления (например, ошибка в
указателе или распределения памяти).
Мое личное мнение состоит в том, что второстепенная или направленная на
представление часть работы сейчас снизилась до половины или менее того от
общего объема. Поскольку эта доля является экспериментальной величиной, ее
значение, в принципе, можно получить путем измерений.5 Если это не удается,
мою оценку можно поправить на основе более полных и более современных
данных, но ни в публичных, ни в частных заявлениях никто не утверждал, что
неосновная часть достигает величины 9/10.
"СПН" с несомненностью доказывает, что если доля неосновной части
работы меньше 9/10, то даже сведя ее к нулю (что было бы чудом), нельзя
получить рост продуктивности на порядок. Атаку необходимо нацелить на
существенную часть.
После появления "СПН" Брюс Блум (Bruce Blum) обратил мое внимание на
работу 1959 года Герцберга, Мознера и Зейдермана (Herzberg, Mausner,
Sayderman).7 Они находят, что факторы мотивации могут увеличить
производительность. С другой стороны, факторы окружения и второстепенные
факторы, сколь бы они ни были положительны, не могут этого сделать, но,
будучи отрицательными, могут уменьшить производительность. В "СПН"
доказывается, что значительная часть прогресса в программной инженерии
достигнута за счет устранения влияния следующих отрицательных факторов:
крайне неудобных машинных языков, пакетной обработки с долгой
оборачиваемостью, слабого инструментария и строгих ограничений на размер
памяти.
Являются ли в таком случае безнадежными трудности, связанные с
сущностью? Отличная работа "Серебряная пуля есть", написанная Бредом Коксом
(Bred Cox) в 1990 году, красноречиво доказывает, что многократно
используемые и взаимозаменяемые компоненты должны послужить основой для
атаки на концептуальную сущность проблемы.8 Я охотно соглашаюсь.
Однако Кокс неправильно понимает "СПН" в двух отношениях. Во-первых, он
находит в ней утверждение того, что трудности разработки программного
обеспечения проистекают из "некоторых порогов технологий, использовавшихся
программистами в то время". Я же доказывал, что трудности, связанные с
сущностью, являются неотъемлемой частью концептуальной сложности
разрабатываемых программных функций во все времена и при любых методах. Во-
вторых, он и многие другие прочли в "СПН" утверждение того, что нет никаких
надежд успешно справиться со сложностями разработки программ, связанными с
вопросами сущности. Это не то, что я имел в виду. Создание концептуальной
конструкции действительно имеет внутренне присущие трудности, такие как
сложность, согласованность, изменяемость и незримость. Однако неприятности,
вызываемые всеми этими трудностями, можно уменьшить.
Сложность разделения на уровни. Например, наиболее серьезной внутренней
трудностью является сложность, но она не всегда неизбежна. Значительная
часть (но не вся) концептуальной сложности в наших программных конструкциях
проистекает от произвольной сложности самих применений. Действительно, Ларс
Седаль из MYSYGMA Sohdal and Partners, международной консалтинговой фирмы в
области менеджмента, пишет:
Мой опыт показывает, что все сложности, с которыми сталкиваются при
разработке систем, являются признаками организационных неполадок. Попытка
моделирования практической деятельности программами соответствующей
сложности влечет сохранение неразберихи вместо решения проблем.
Стив Лукашик (Steve Lukasik) из Northrop доказывает, что даже
организационная сложность, возможно, не является произвольной, а может
испытывать воздействие принципов упорядочения:
Я получил образование в облати физики и поэтому вижу, что "сложные"
вещи могут быть описаны на языке более простых понятий. Вы можете быть
правы, и я не стану утверждать, что все сложные вещи поддаются принципам
упорядочения... по тем же правилам доказательства нельзя утверждать, что не
поддаются.
...То, что вчера было сложностью, завтра будет в порядке вещей.
Сложность беспорядочного движения молекул привела к возникновению
кинетической теории газов и открытию трех законов термодинамики. Сейчас
программное обеспечение не позволяет увидеть присущие ему принципы
упорядочения, но вы как раз и должны объяснить, почему это происходит. Это
не проявление моей бестолковости или желания поспорить. Я убежден, что в
один прекрасный день "сложность" программного обеспечения будет объяснена на
языке каких- нибудь понятий более высокого порядка (инвариантов, как говорят
физики).
Я не занимался более глубоким анализом, к которому справедливо
призывает Лукашик. Как отрасль науки мы нуждаемся в развитии теории
информации для количественной оценки информационного содержания
статистических структур, подобно тому, как теория Шэннона делает это для
информационных потоков. Это совсем не моя задача. Лукашику я просто отвечу,
что сложность системы является функцией мириадов деталей, каждая из которых
должна быть точно задана либо с помощью какого-нибудь общего правила, либо
подробным описанием, но не просто статистически. Представляется весьма
сомнительным, чтобы несогласованные результаты работы многих голов оказались
достаточно связными, чтобы быть точно описанными общими правилами.
Значительно большая часть сложности программных конструкций
обусловлена, однако, не соответствием внешнему миру, а самой реализацией -
структурами данных, алгоритмами, способами коммуникаций. Наращивание
программ с помощью больших блоков высокого уровня, созданных когда-то раньше
Unix. Даже инструменты и среды программирования могут быть куплены в
коробочном виде. Я где-то предложил базар для отдельных модулей.
Любой такой продукт дешевле купить, чем создавать заново. Даже при цене
100 000 долларов купленный продукт стоит примерно столько, сколько годовое
содержание программиста. И поставка немедленная! Немедленная, по крайней
мере, для реально существующих продуктов, проспект которых разработчик может
послать счастливому пользователю. Более того, такие продукты обычно гораздо
лучше документированы и несколько лучше сопровождаются, чем доморощенные
программы.
Развитие массового рынка является, по моему мнению, наиболее глубокой
долгосрочной тенденцией программной инженерии. Стоимость программного
продукта всегда определялась стоимостью разработки, а не тиражирования.
Разделив эту стоимость даже на нескольких пользователей, мы коренным образом
снижаем цену на одного пользователя. Взглянув на это с другой стороны, мы
видим, что использование n копий программной системы фактически умножает на
n производительность его разработчиков. Это рост производительности отрасли
и всей страны.
Главным вопросом, конечно, является производительность. Смогу ли я
использовать имеющийся коробочный продукт для решения своих задач? Здесь
случилась удивительная вещь. В 50-х и 60-х годах одно исследование за другим
показывало, что пользователи не хотят использовать коробочные пакеты для
расчета зарплаты, управления складом, учета дебиторов по расчетам и т.д.
Требования были слишком специальными, отклонения от случая к случаю слишком
большими. В 80-х годах мы обнаруживаем большой спрос на такие пакеты и
широкое их использование. Что изменилось?
Только не пакеты. Они стали несколько более общими и лучше
настраиваются, чем раньше, но не намного. И не область их применения. В
конце концов, сегодня потребности бизнеса и науки более разнообразны и
сложны, чем 20 лет назад.
Резко изменилось соотношение стоимости компьютеров и программ. Тот, кто
в 1960 году покупал машину за 2 миллиона долларов, считал, что может
позволить себе потратить еще 250 000 долларов на заказную программу расчета
зарплаты, которая легко и без ущерба вписалась бы во враждебную компьютерам
социальную среду. Те, кто сегодня покупают машину для офиса за 50 000
долларов, не могут, понятно, позволить себе заказные программы расчета
зарплаты, поэтому они приспосабливают свои процедуры расчета зарплаты к
имеющимся пакетам. Компьютеры сейчас столь обычны, если не столь любимы, что
адаптация воспринимается как обычное дело.
Есть яркие исключения из моего утверждения о том, что обобщенность
программных пакетов за последние годы мало изменилась: электронные таблицы и
простые системы баз данных. Эти мощные инструменты, столь очевидные задним
умом и так поздно появившиеся, имеют бесчисленное множество применений, в
том числе, весьма необычные. Есть масса статей и даже книг о том, как с
помощью электронной таблицы решать неожиданные задачи. Большое число задач,
для которых раньше были бы написаны заказные программы на Cobol или Report
Program Generator, теперь шаблонно решается с помощью этих инструментов.
Многие пользователи изо дня в день применяют свои компьютеры для разных
приложений, никогда не написав ни одной программы. На практике многие из
этих пользователей и не могут писать для своих машин новые программы, но тем
не менее приверженцы решению возникающих задач с их помощью.
Я считаю, что сегодня для многих организаций самая правильная политика
для повышения производительности разработки программного обеспечения - это
установить своим не имеющим компьютерных знаний работникам умственного труда
компьютеры и хорошие общие программы для обработки текстов, рисования,
работы с файлами и электронными таблицами и отпустить их в вольное плавание.
Такая же политика в отношении распространенных математических и
статистических пакетов, а также некоторых навыков программирования подойдет
сотням ученых, работающих в лабораториях.
Уточнение требований и быстрое макетирование. Самая трудная отдельная
задача в разработке программной системы - это точно решить, что
разрабатывать. Ни одна другая задача работы над концепциями не является
столь трудной, как разработка подробных технических требований, включая все
интерфейсы пользователей, машинные интерфейсы и интерфейсы к другим
программным системам. Ни одна другая часть работы не наносит такого ущерба
готовой системе, если сделана неправильно. Ни одна другая часть не
исправляется позднее с бoльшим трудом.
Поэтому наиболее важной функцией, осуществляемой разработчиками для
своих клиентов, является повторяющееся получение и уточнение требований к
продукту. Правда заключается в том, что клиенты не знают, чего хотят. Обычно
они не знают, на какие вопросы нужно дать ответ, и почти никогда не
задумывались над задачей настолько детально, как это нужно указать в
спецификации. Даже простой ответ - "сделайте так, чтобы новая программная
система работала так, как наша старая ручная система обработки информации" -
оказывается в действительности слишком упрощенным. Клиенты никогда не хотят
этого в точности. Более того, сложные программные системы действуют,
движутся, работают. Динамику этого действия трудно себе представить. Поэтому
при планировании любых действий необходимо оставить резерв для многократного
взаимодействия между клиентом и проектировщиком при описании системы.
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе
с инженерами-программистами, не в состоянии указать полно, строго и
корректно точные требования к современному программному продукту, прежде чем
будут созданы и опробованы какие-либо версии продукта, спецификации к
которому они составляют.
Поэтому одним из наиболее многообещающих современных направлений в
технологии, причем обращенных к сущности, а не к акциденциям проблем
программирования, является разработка подходов и инструментов для быстрого
создания макетов систем как части итеративного процесса разработки
спецификаций.
Макет программной системы моделирует главные интерфейсы и выполняет
основные функции предполагаемой системы, при этом не обязательно будучи
связан теми же ограничениями быстродействия компьютера, размера или
стоимости. Обычно макеты выполняют основные задачи системы, но не пытаются
обрабатывать исключительные ситуации, правильно реагировать на ввод
недопустимых данных, корректно прерывать работу и т.д. Назначение макета -
показать, как воплощается выбранная концептуальная структура, чтобы клиент
мог проверить ее пригодность к использованию и непротиворечивость.
Сегодня многие процедуры приобретения программного обеспечения
основываются на предположении, что можно заранее задать технические
требования для желаемой системы, рассмотреть предложения разработчиков,
получить разработанную систему и установить ее. Я думаю, что такое
предположение в корне неверно, и из-за этой ошибки проистекают многие
проблемы при приобретении программ, поскольку эти проблемы нельзя устранить
без пересмотра основ, для которого требуется интерактивная разработка и
спецификации макетов и продуктов.
Пошаговая обработка: наращивать программу, а не строить сразу. Я до сих
пор помню испытанный в 1958 году удар, когда впервые услышал, как мой друг
говорил о строительстве (building) программ в противоположность написанию
(writing). В мгновение он расширил все мое представление о процессе
программирования. Применение метафоры было сильным и точным. Сегодня мы
понимаем, что сходство существует между созданием программы и другими
строительными процессами, и свободно используем другие элементы метафоры,
такие как спецификации (specifications), сборка компонентов (assembly of
components), леса (scaffolding).
Метафора строительства пережила свое время. Пора снова вносить
изменения. Если, как я считаю, создаваемые сегодня концептуальные структуры
слишком сложны, чтобы их можно было точно специфицировать заранее, и слишком
сложны, чтобы строить без ошибок, тогда нужен радикально иной подход.
Обратимся к природе и рассмотрим сложность живых созданий, а не
безжизненных творений человека. Там мы обнаруживаем конструкции, сложность
которых вселяет в нас ужас. Один только мозг настолько сложен, что
невозможно составить его схему. Его мощь невозможно повторить, он богат
своеобразием, способен к самосохранению и самообновлению. Секрет в том, что
мозг растет, а не строится.
Так же должны создаваться наши программные системы. Несколько лет назад
Харлан Миллз предложил наращивать программные системы путем пошаговой
разработки.11 Это значит, что сначала систему надо заставить выполняться,
даже если при этом она не делает ничего полезного, кроме вызова некоторого
числа фиктивных подпрограмм. Затем она понемногу обрастает мясом, причем
подпрограммы, в свою очередь, разрабатываются сначала как вызовы пустых
фиктивных подпрограмм, находящихся на уровень ниже.
Настаивая на применении этой технологии разработчиками проектов на моих
лабораторных занятиях по программной инженерии, я стал свидетелем
поразительных результатов. За последнее десятилетие ничто другое не оказало
столь сильного влияния на мою собственную работу и ее эффективность. Этот
подход предполагает нисходящее проектирование, поскольку это - нисходящее
наращивание программы. Он позволяет легко отслеживать работу в обратном
направлении. Он предоставляет возможность раннего создания макетов. Каждая
новая функция или возможность работы с более сложными данными или условиями
органически вырастают на того, что уже имеется.
Воздействие на моральный дух ошеломительное. Когда есть хотя бы простая
работающая система, возрастает энтузиазм. Энергия удваивается, когда на
экране появляется картинка из новой графической программной системы, даже
если это всего лишь прямоугольник. И на каждой стадии процесса разработки
существует работающая система. Я считаю, что за одинаковые сроки команда
может нарастить значительно более сложный объект, чем построить.
В больших проектах можно ощутить такие же выгоды, как и в моих
маленьких.12
Выдающиеся проектировщики. Главная проблема совершенствования искусства
программирования заключена, как всегда, в людях.
Мы можем добиваться хороших проектов, следуя хорошим, а не плохим
практическим приемам. Хорошим приемам можно обучать. Программисты
принадлежат к наиболее интеллектуальной части общества, следовательно, они в
состоянии изучать хорошие приемы. Поэтому важнейшим направлением в
Соединенных Штатах является распространение хороших современных приемов.
Новые курсы, новые издания, новые организации, такие как Институт инженеров-
программистов (Software Engineering Institute) - все это вызвано к жизни
стремлением повысить уровень наших практических приемов. Это совершенно
правильно.
Тем не менее, я считаю, что мы не сможем подняться еще на одну
ступеньку выше, действуя в этом направлении. Выбор правильного метода
проектирования определяет различия между плохим и хорошим концептуальным
проектом, но не между хорошим и выдающимся. Выдающиеся проекты создаются
выдающимися проектировщиками. Создание программ является творческим
процессом. Крепкая методология может придать силу и освободить творческий
ум, но она не может воспламенить или вдохновить того, кто занят нудной
работой.
И разница немалая - это как Сальери и Моцарт. Одно исследование за
другим показывают, что лучшие проектировщики создают структуры, которые
быстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями.
Различия между выдающимся и средним достигают порядка величины.
Нетрудно проследить, что ряд хороших и полезных программных систем
проектировался комиссиями и создавался с помощью проектов, состоявших из
многих частей. Но программные системы, вызвавшие восхищение страстных
поклонников, являются продуктом одного или небольшого числа выдающихся
проектировщиков. Посмотрите на Unix, APL, Pascal, интерфейс Smalltalk и даже
Fortran - с одной стороны, и Cobol, PL/I, Algol, MVS/370 и MS-DOS - с другой
(рис. 16.1).
Рис. 16.1 Имеются ли у этих продуктов страстные поклонники?
Поэтому, высоко ценя нынешние программы передачи технологий и развития
обучения, я считаю, что наиболее важной программой, которую мы можем
предпринять, является развитие способов воспитания выдающихся
проектировщиков.
Ни одна занятая в программировании организация не может игнорировать
эту проблему. Хороших менеджеров, как бы мало их ни было, не меньше, чем
хороших проектировщиков. Как выдающиеся проектировщики, так и выдающиеся
менеджеры встречаются редко. В большинстве организаций значительные усилия
тратятся на поиска и выращивание подающих надежды менеджеров. Я не слышал,
чтобы кто- либо тратил такие же усилия на поиски и развитие выдающихся
проектировщиков, от которых, в конечном счете, зависит техническое
превосходство продуктов.
Первое мое предложение состоит в том, чтобы каждая занятая в
программировании организация определила для себя и провозгласила, что
выдающиеся проектировщики имеют для ее успеха такое же большое значение, как
и выдающиеся менеджеры, и что они могут рассчитывать на такие же заботу и
вознаграждение. Не только зарплата, но и атрибуты положения - размеры офиса,
мебель, техническое оборудование, командировочные фонды, обеспеченность
сотрудниками - должны быть полностью равнозначны.
Как растить выдающихся проектировщиков? Место не позволяет обсуждать
это пространно, но вот некоторые очевидные шаги:
- Систематически и как можно раньше выявлять первоклассных
проектировщиков. Лучшие - не всегда самые опытные.
- Назначить наставника, ответственного за рост перспективного
проектировщика и тщательно следить за его карьерой.
- Разработать и осуществлять план служебного роста для каждого
перспективного проектировщика, включающий тщательно продуманное обучение у
передовых проектировщиков, периоды дополнительного формального обучения,
краткосрочные курсы, перемежающиеся с самостоятельным проектированием и
назначением на руководящие технические должности.
- Обеспечить возможности для взаимодействия и взаимного стимулирования
растущих проектировщиков.
У всякой пули - свое
предназначение.
ВИЛЬГЕЛЬМ III ОРАНСКИЙ
Кто хочет увидеть образец совершенства,
Тот мечтает о том, чего никогда не было,
нет и не будет.
АЛЕКСАНДР ПОП, "О КРИТИКЕ"
Об оборотнях и прочих мифических ужасах
"Серебряной пули нет: сущность и акциденция в программной инженерии"
(глава 16 данной книги) первоначально была заказным докладом для конференции
IFIP (Международной федерации по обработки информации) 1986 года в Дублине и
была опубликована в ее трудах.1 Журнал "Computer" перепечатал ее под
обложкой в готическом стиле, иллюстрируя кадрами из фильмов, таких как
"Вервольф из Лондона",2 и снабдив боковым полем "Убить вервольфа" с
изложением современной легенды о том, что справиться с ним можно только с
помощью серебряной пули. До публикации я не знал об иллюстрациях, и для меня
было неожиданностью, что серьезная техническая статья была так красочно
издана.
Однако редакторы "Computer" знали свое дело и достигли желаемого
результата: похоже, что статью прочли многие. Поэтому я подобрал для той
главы еще одну картинку с оборотнем - старинное изображение почти забавного
создания. Надеюсь, что эта менее яркая картинка окажет такое же полезное
действие.
Серебряная пуля все-таки есть - ВОТ ОНА!
"Серебряной пули нет" утверждает и доказывает, что в течение
десятилетия (с момента публикации статьи в 1986 году) ни одна разработка в
области техники программного обеспечения не позволит повысить
производительность труда в программировании на порядок. Из этого десятилетия
прошло уже девять лет, и можно посмотреть, насколько сбывается предсказание.
В то время как "Мифический человеко-месяц" породил частое цитирование и
мало споров, статья "Серебряной пули нет" вызвала статьи с опровержениями и
письма в редакции журналов, поток которых не прекратился и по сей день.3
Чаще всего критикуется главное утверждение о том, что волшебного решения
нет, и мое ясно выраженное мнение о том, что его и быть не может.
Большинство соглашается с основной частью моих аргументов в "СПН", но затем
заявляет, что в действительности серебряная пуля для программного зверя
существует, и изобрел ее автор. Перечитывая сегодня ранние отклики, не могу
не отметить, что патентованные средства, столь энергично предлагавшиеся в
1986 и 1987 годах, не возымели эффекта, на который претендовали.
Я обычно покупаю компьютеры и программы, проверяя их на "счастливом
обладателе", т.е. беседуя с вызывающими доверие людьми, заплатившими деньги
за продукт и пользующимися им с удовольствием. Аналогично, я с готовностью
поверю в материализацию серебряной пули, когда вызывающий доверие
независимый пользователь выступит вперед и скажет: "Я использовал эту
методологию, этот инструмент или продукт, и это позволило мне в десять раз
повысить производительность разработки программ".
Многие корреспонденты сделали верные поправки и разъяснения. Некоторые
проанализировали статью пункт за пунктом и привели возражения, за что я им
благодарен. В этой главе я хочу сообщить о сделанных поправках и ответить на
опровержения.
Неясное изложение влечет непонимание
Судя по некоторым откликам, мне не удалось четко изложить свои
аргументы.
Второстепенное свойство (accident). В резюме главы 16 я постарался со
всей возможной ясностью изложить основные аргументы "СПН". Некоторые,
однако, были смущены терминами второстепенное свойство (accident) и
несущественный, второстепенный (accidental), которые я использовал в старом
употреблении, восходящем к Аристотелю.4 Под accidental я не имел в виду
"случайный" или "относящийся к несчастному случаю", а скорее,
"несущественный", "побочный" (incidental) или "принадлежащий" (appurtinent).
Я не хочу порочить роль случайности при разработке программ. Вслед за
английским драматургом, автором детективов и теологом Дороти Сэйерс (Dorothy
Sayers) я рассматриваю всякую творческую деятельность, как состоящую из: а)
формулирования концептуальных конструкций, б) воплощения в реальном
материале и в) диалога с пользователем в реальной жизни.5 Та часть
построения программы, которую я назвал сущностью (essence), состоит из
умственной работы создания концепутальной конструкции, а та, которую я
назвал второстепенной (accident), есть процесс ее воплощения.
Выяснение истины. Мне кажется (хотя не все со мной согласны), что
верность центрального аргумента сводится к выяснению ответа на вопрос: какая
доля затрат связана с точным и упорядоченным представлением концептуальной
конструкции, а какая - с умственными усилиями по изготовлению этих
конструкций. Поиск и устранение ошибок попадают в тот или иной раздел в
зависимости от того, являются ли ошибки концептуальными (например, пропуск
какого-либо особого случая) или ошибками представления (например, ошибка в
указателе или распределения памяти).
Мое личное мнение состоит в том, что второстепенная или направленная на
представление часть работы сейчас снизилась до половины или менее того от
общего объема. Поскольку эта доля является экспериментальной величиной, ее
значение, в принципе, можно получить путем измерений.5 Если это не удается,
мою оценку можно поправить на основе более полных и более современных
данных, но ни в публичных, ни в частных заявлениях никто не утверждал, что
неосновная часть достигает величины 9/10.
"СПН" с несомненностью доказывает, что если доля неосновной части
работы меньше 9/10, то даже сведя ее к нулю (что было бы чудом), нельзя
получить рост продуктивности на порядок. Атаку необходимо нацелить на
существенную часть.
После появления "СПН" Брюс Блум (Bruce Blum) обратил мое внимание на
работу 1959 года Герцберга, Мознера и Зейдермана (Herzberg, Mausner,
Sayderman).7 Они находят, что факторы мотивации могут увеличить
производительность. С другой стороны, факторы окружения и второстепенные
факторы, сколь бы они ни были положительны, не могут этого сделать, но,
будучи отрицательными, могут уменьшить производительность. В "СПН"
доказывается, что значительная часть прогресса в программной инженерии
достигнута за счет устранения влияния следующих отрицательных факторов:
крайне неудобных машинных языков, пакетной обработки с долгой
оборачиваемостью, слабого инструментария и строгих ограничений на размер
памяти.
Являются ли в таком случае безнадежными трудности, связанные с
сущностью? Отличная работа "Серебряная пуля есть", написанная Бредом Коксом
(Bred Cox) в 1990 году, красноречиво доказывает, что многократно
используемые и взаимозаменяемые компоненты должны послужить основой для
атаки на концептуальную сущность проблемы.8 Я охотно соглашаюсь.
Однако Кокс неправильно понимает "СПН" в двух отношениях. Во-первых, он
находит в ней утверждение того, что трудности разработки программного
обеспечения проистекают из "некоторых порогов технологий, использовавшихся
программистами в то время". Я же доказывал, что трудности, связанные с
сущностью, являются неотъемлемой частью концептуальной сложности
разрабатываемых программных функций во все времена и при любых методах. Во-
вторых, он и многие другие прочли в "СПН" утверждение того, что нет никаких
надежд успешно справиться со сложностями разработки программ, связанными с
вопросами сущности. Это не то, что я имел в виду. Создание концептуальной
конструкции действительно имеет внутренне присущие трудности, такие как
сложность, согласованность, изменяемость и незримость. Однако неприятности,
вызываемые всеми этими трудностями, можно уменьшить.
Сложность разделения на уровни. Например, наиболее серьезной внутренней
трудностью является сложность, но она не всегда неизбежна. Значительная
часть (но не вся) концептуальной сложности в наших программных конструкциях
проистекает от произвольной сложности самих применений. Действительно, Ларс
Седаль из MYSYGMA Sohdal and Partners, международной консалтинговой фирмы в
области менеджмента, пишет:
Мой опыт показывает, что все сложности, с которыми сталкиваются при
разработке систем, являются признаками организационных неполадок. Попытка
моделирования практической деятельности программами соответствующей
сложности влечет сохранение неразберихи вместо решения проблем.
Стив Лукашик (Steve Lukasik) из Northrop доказывает, что даже
организационная сложность, возможно, не является произвольной, а может
испытывать воздействие принципов упорядочения:
Я получил образование в облати физики и поэтому вижу, что "сложные"
вещи могут быть описаны на языке более простых понятий. Вы можете быть
правы, и я не стану утверждать, что все сложные вещи поддаются принципам
упорядочения... по тем же правилам доказательства нельзя утверждать, что не
поддаются.
...То, что вчера было сложностью, завтра будет в порядке вещей.
Сложность беспорядочного движения молекул привела к возникновению
кинетической теории газов и открытию трех законов термодинамики. Сейчас
программное обеспечение не позволяет увидеть присущие ему принципы
упорядочения, но вы как раз и должны объяснить, почему это происходит. Это
не проявление моей бестолковости или желания поспорить. Я убежден, что в
один прекрасный день "сложность" программного обеспечения будет объяснена на
языке каких- нибудь понятий более высокого порядка (инвариантов, как говорят
физики).
Я не занимался более глубоким анализом, к которому справедливо
призывает Лукашик. Как отрасль науки мы нуждаемся в развитии теории
информации для количественной оценки информационного содержания
статистических структур, подобно тому, как теория Шэннона делает это для
информационных потоков. Это совсем не моя задача. Лукашику я просто отвечу,
что сложность системы является функцией мириадов деталей, каждая из которых
должна быть точно задана либо с помощью какого-нибудь общего правила, либо
подробным описанием, но не просто статистически. Представляется весьма
сомнительным, чтобы несогласованные результаты работы многих голов оказались
достаточно связными, чтобы быть точно описанными общими правилами.
Значительно большая часть сложности программных конструкций
обусловлена, однако, не соответствием внешнему миру, а самой реализацией -
структурами данных, алгоритмами, способами коммуникаций. Наращивание
программ с помощью больших блоков высокого уровня, созданных когда-то раньше