WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 | 2 || 4 |

«Мифический человеко-месяц Мифический человеко-месяц Мифический человеко-месяц или как создаются программные системы или как создаются программные системы или как создаются программные системы ...»

-- [ Страница 3 ] --

Более того, с некоторого момента дальнейшая разработка языков высокого уровня становится обузой, осложняющей, а не упрощающей интеллектуальные задачи пользователя, редко использующего эзотерические конструкции.

Разделение времени. Большинство исследователей считает, что благодаря работе в режиме разделения времени произошел большой рост производительности труда программистов и качества создаваемых программных продуктов, хотя и не такой значительный, как вызванный использованием языков высокого уровня.

Разделение времени помогает решить совсем другую задачу. Благодаря разделению времени обеспечивается безотлагательность, и потому возможность иметь общее впечатление о сложности. Из-за медленной оборачиваемости при пакетной обработке мы неизбежно забываем мелочи, если не самое направление нашей мысли, в тот момент, когда мы прервались и начали компиляцию и выполнение программы. Этот обрыв мысли дорого обходится по времени, поскольку приходится восстанавливать ее в памяти. В худшем случае, можно вообще потерять представление о том, что происходит со сложной системой.

Медленная оборачиваемость, как и сложности машинных языков, является второстепенной, а не существенной трудностью процесса программирования.

Предельный вклад, вносимый разделением времени, определяется непосредственно.

Главное — это сократить время отклика системы. По мере приближения его к нулю, оно переходит порог скорости человеческого восприятия, составляющей около миллисекунд. Дальше никакой выгоды получить уже нельзя.

Объединенные среды программирования. Считается, что Unix и Interlisp, первые широко распространенные интегрированные среды программирования, повысили производительность в несколько раз. Почему?

Они направлены на преодоление второстепенных трудностей совместного использования программ путем использования общих библиотек, унифицированных форматов файлов, каналов и фильтров. В результате концептуальные структуры, которые, в принципе, всегда могут вызывать, обмениваться данными и использовать друг друга, получают возможность осуществлять это практически.

Это достижение, в свою очередь, стимулировало развитие целых инструментальных наборов, поскольку всякий новый инструмент мог применяться к любым программам, используя стандартные форматы.

Благодаря этим успехам среды программирования стали предметом многих сегодняшних исследований в программной инженерии. В следующем параграфе мы рассмотрим, что от них можно ожидать, и какие им присуще ограничения.

Надежды на серебро Рассмотрим теперь те технические достижения, которые чаще всего выдвигаются кандидатами на роль серебряной пули. К каким задачам они обращаются? Задачам, относящимся к сущности, или остаткам наших акцидентных сложностей? Предлагают ли они революционное развитие или пошаговое продвижение?

Ada и другие достижения языков высокого уровня. Одним из наиболее рекламируемых достижений последнего времени является язык программирования Ada — язык высокого уровня общего назначения 80-х годов. Ada действительно не только отражает эволюционное развитие концепций языков, но и воплощает черты, поддерживающие современные идеи проектирования и модульности. Возможно, большим достижением является не язык Ada, а философия Ada как философия модульности, абстрактных типов данных, иерархического структурирования. Ada, пожалуй перегружен возможностями, будучи естественным продуктом процесса, породившего требования, положенные в основу его разработки. Это не смертельно, поскольку подмножества рабочих словарей могут решить проблему изучения, а прогресс электроники даст нам дешевые миллионы операций в секунду, решающие проблему компиляции. Развитие структурированности программных систем — это очень хорошее применение для денег, которые мы тратим на приобретение все больших вычислительных мощностей. Операционные системы, громко осуждавшиеся в 60-х годах за дороговизну памяти и вычислений, оказались хорошим способом применения быстродействия и дешевой памяти, полученных в результате быстрого развития аппаратных средств.

Тем не менее Ada не станет той серебряной пулей, которая уложит монстра низкой производительности производства программного обеспечения. В конце концов это всего лишь еще один язык высокого уровня, а самую большую отдачу от применения таких языков мы уже получили при первом переходе от второстепенной сложности машин к более абстрактной формулировке пошаговых решений. После устранения тех акциденций остались менее существенные, и выгоды от их устранения будет, конечно, меньше.

Я предвижу, что через десятилетие, когда оценят эффективность Ada, будет признан значительный вклад этого языка, но не благодаря какой-либо отдельной его возможности и даже не благодаря им всем вместе взятым. Не станут причиной успехов и новые среды программирования на Ada. Наибольшим вкладом Ada явится то, что переход на этот язык послужит причиной изучения программистами современных методов проектирования программного обеспечения.

Объектно-ориентированное программирование. Многие, изучающие искусство программирования, связывают с объектно-ориентированным программированием больше надежд, чем с любыми другими современными техническими увлечениями. Я принадлежу к их числу. Марк Шерман (Mark Sherman) из Дартмута замечает, что следует проводить отличие между двумя разными идеями, фигурирующими под этим названием: абстрактных типов данных и иерархических типов, называемых также классами. Понятие абстрактного типа данных состоит в том, что тип объекта определяется именем, множеством допустимых значений и множеством допустимых операций, а не организацией хранения, которая должна быть скрыта. Примерами являются пакеты Ada (с защищенными типами) и модули в языке Modula.

Иерархические типы, такие классы в Simula-67, позволяют определять общие интерфейсы, которые в дальнейшем можно уточнять с помощью подчиненных типов.

Эти две концепции ортогональны: могут быть открытые иерархии и скрытие без иерархий. Обе концепции действительно являются достижением в искусстве программирования.

Каждая из них устраняет еще одну второстепенную сложность, позволяя разработчику выразить сущность своего проекта без использования большого количества синтаксического материала, не добавляющего нового информационного содержания. Использование как абстрактных, так и иерархических типов устраняет второстепенные трудности более высокого порядка и позволяет выразить проект на более высоком уровне.

И все же такие достижения могут не более чем устранить второстепенные трудности при выражении проекта. Существенна сложность самого проекта, на что решение таких задач никак не может повлиять. Добиться выигрыша на порядок величин с помощью объектно-ориентированного программирования можно лишь в том случае, если остающаяся сегодня в нашем языке программирования необязательная работа по спецификации типов сама по себе ответственна за 9/10 усилий, затрачиваемых на проектирование программного продукта. В этом я не сомневаюсь.

Искусственный интеллект. Многие ожидают, что успехи в области искусственного интеллекта позволят осуществить революционный переворот, который принесет рост производительности разработки программного обеспечения и его качества на порядки величин.4 Я этого не жду. Чтобы увидеть, почему, разберем, что понимается под «искусственным интеллектом», а затем посмотрим, какие возможны применения.

Парнас внес ясность в терминологический хаос:

Сегодня в ходу два совершенно разных определения ИИ. ИИ-1: использование компьютеров для решения задач, которые раньше могли быть решены только с помощью человеческого интеллекта. ИИ-2: использование специальных приемов программирования, известных как эвристическое, или основанное на правилах, программирование. При таком подходе изучают действия экспертов, чтобы определить, какими эвристиками и практическим правилами они пользуются при решении задач... Программа корректируется для решения задач так, как, по-видимому, ее решает человек.

У первого определения скользкий смысл... Кое-что укладывается сегодня в определение ИИ-1, но как только мы видим работу программы и понимаем задачу, мы уже не думаем о ней, как о ИИ... К несчастью, я не вижу ядра методов, которые уникальны в этой области... По большей части методы проблемно-ориентированны, и для их переноса требуются известные абстракция и творчество. Я полностью согласен с этой критикой. Приемы, используемые для распознавания речи, выказывают мало сходства с методами распознавания изображений, при этом в экспертных системах используются методы, отличные от тех и других. Я затрудняюсь сказать, к примеру, какое влияние распознавание изображений может оказать на методы программирования. То же самое справедливо в отношении распознавания речи. При разработке программ трудно решить, что именно сказать, а не собственно сказать. Никакое облегчение выражения не может дать больше, чем незначительные выгоды.

Методы экспертных систем ИИ-2 заслуживают отдельного параграфа.

Экспертные системы. Наиболее развитой и широко применяемой частью искусственного интеллекта являются экспертные системы. Многие ученые в области программирования напряженно трудятся над применением этой технологии в средах разработки программного обеспечения.5 В чем состоит идея, и каковы перспективы?

Экспертная система — это программа, содержащая обобщенный генератор выводов и базу правил, предназначенную для приема входных данных и допущений и исследования логических следствий через заключения, выводимые из базы правил, предоставляющая заключения и рекомендации и предлагающая пользователю объяснение полученных результатов путем обратного прослеживания своих рассуждений. Помимо чисто детерминированной логики, генератор выводов обычно может работать с нечеткими или вероятностными данными.

Такие системы предоставляют некоторые явные преимущества перед запрограммированными алгоритмами решения тех же задач:

• Технология генератора выводов разрабатывается независимо от применения и используется затем во многих приложениях.

• Изменяемые части специфических для приложения данных единообразно кодируются в базе правил. Обеспечивается инструментарий для разработки, изменения, проверки и документирования базы правил. Этим упорядочивается значительная часть сложности самого приложения.

Эдвард Фейгенбаум (Edward Feigenbaum) считает, что мощь таких систем растет не благодаря совершенствованию механизмов вывода, а скорее, благодаря пополнению базы знаний, все более точно отражающей реальный мир. Я считаю, что самое важное достижение этой технологии состоит в разделении сложности приложения и самой программы.

Как можно использовать экспертные системы при создании программного обеспечения? Различными способами: предложение правил интерфейсов, рекомендации по стратегии отладки, запоминание частоты ошибок каждого типа, подсказки по оптимизации и т.п.

Представим себе, к примеру, некоего советчика по отладке. В самой зачаточной форме диагностическая экспертная система весьма напоминает памятку пилота, по сути, делая предположения относительно возможных причин затруднений. По мере развития базы правил предположения становятся более специфичными, более изощренно учитывая симптомы проблемы. Можно представить такого помощника предлагающим сначала самые общие решения, но, по мере воплощения в базе правил все большей части структуры системы, становящегося все более разборчивым в генерируемых гипотезах и предлагаемых тестах. Такая экспертная система может решительно отличаться от обычных тем, что ее база правил, вероятно, должна быть иерархически разбита на модули таким же образом, как соответствующий программный продукт. Поэтому при изменении модульной структуры продукта изменяется также модульная структура базы диагностических правил.

Работа, которую необходимо проделать для создания диагностических правил, в любом случае должна быть проведена при создании набора контрольных примеров для модулей и для системы. Если это делать достаточно общим образом, с единообразной структурой правил и при наличии хорошего генератора выводов, то можно действительно сократить объем работ при генерации контрольных примеров, а также пожизненном сопровождении и тестировании модификаций. Такие же условия мы можем поставить и для других советчиков, используемых для других участников задачи создания программы. Возможно, они будут многочисленны и иногда просты.

На пути ранней реализации полезных экспертных советников для разработчика программы стоит много препятствий. Решающей частью нашего воображаемого сценария является разработка простых способов перехода от задания структуры программы к автоматическому или полуавтоматическому созданию диагностических правил. Еще более сложной и важной является двойная задача приобретения знаний: найти членораздельно выражающихся и способных к самоанализу экспертов, понимающих, почему они делают то или другое действие, и разработать эффективные методы извлечения их знаний и превращения в базы правил. Чтобы построить экспертную систему, необходимо иметь эксперта.

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

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

Короче, автоматическое программирование всегда было эвфемизмом для программирования на языке более высокого уровня, чем доступный программисту в данный момент. Он утверждает, в сущности, что в большинстве случаев нужно задать спецификацию не задачи, а метода решения.

Можно отыскать исключения. Метод создания генераторов является очень мощным и повседневно с пользой применяется в программах сортировки. Некоторые системы интегрирования дифференциальных уравнений также позволяли прямую формулировку задачи. Система производила оценку параметров, выбирала из библиотеки методы решения и генерировала программы.

У этих применений есть свойства, благоприятствующие автоматизации:

• Проблемы легко описываются сравнительно небольшим числом параметров.

• Известно много методов решения, что обеспечивает наличие библиотеки альтернатив.

• Тщательный анализ привел к выработке явных правил выбора методов решения в зависимости от параметров.

Едва ли возможно обобщение таких методов на весь мир обычных программных систем, в котором ситуация с такими приятными свойствами являются исключениями. Трудно даже представить себе, как такой прорыв в обобщении мог бы произойти разумным образом.

Графическое программирование. Излюбленной темой докторских диссертаций в программной инженерии является графическое, или визуальное, программирование — применение компьютерной графики в разработке программного обеспечения. Иногда перспективы такого подхода основываются на аналогии с проектированием СБИС, в котором компьютеры играют такую большую роль. Иногда такой подход обосновывается, исходя из того, что блок-схемы являются идеальным материалом при проектировании программ. Имеются мощные средства для создания таких блок схем.

Ничего убедительного и удивительного из этих попыток пока не вышло, — и я уверен, не выйдет.

Во-первых, как я всюду доказываю, блок-схема является весьма слабой абстракцией структуры программы.10 Лучше всего это видно из попыток Беркса, фон Неймана и Гольдстайна снабдить свой предполагаемый компьютер крайне необходимым управляющим языком высокого уровня. В том жалком виде — многие страницы соединенных линиями прямоугольников, — в котором сегодня разрабатываются блок-схемы, они доказали, в сущности, свою бесполезность: программисты рисуют их после, а не до создания описываемых ими программ.

Во-вторых, сегодняшние экраны имеют слишком мало пикселов, чтобы показать целиком и с достаточным разрешением сколько-нибудь подробную схему программы.

Так называемая «метафора рабочего стола» становится метафорой «сиденья самолета». Всякий, кому приходилось листать пачку бумаг, будучи стиснутым двумя корпулентными соседями, почувствует разницу: одновременно можно увидеть очень немного. Настоящий рабочий стол позволяет обозревать и произвольно выбирать множество бумаг. Более того, в порыве творчества не один программист или писатель предпочитал рабочему столу более вместительный пол. Аппаратным технологиям нужно сделать очень большой наг, чтобы предоставляемый экранами обзор был достаточным для задач проектирования программ.

Если обратиться к основам, программное обеспечение очень трудно визуализировать, как я доказывал это выше. Составляем ли мы схемы управляющей логики, вложенных областей, видимости переменных, перекрестных ссылок переменных, потоков данных, иерархических структур данных или чего-то еще, они отражают лишь одно изменение взаимодействующих запутанным образом частей программной системы. Если наложить одна на другую эти схемы, отражающие взгляд с различных точек зрения, трудно извлечь из этого какую-либо общую точку зрения.

Аналогия с интегральными схемами вводит, в сущности, в заблуждение: конструкция микросхемы представляет собой многослойный двумерный объект, геометрия которого отражает сущность. Программная система не является таким объектом.

Верификация программ. Много труда в современном программировании тратится на отладку и исправление ошибок. Может быть, мы найдем серебряную пулю, устранив все ошибки в самом начале, на этапе системного проектирования? Можно ли радикально повысить производительность и надежность продукта, если следовать совершенно иной стратегии — обеспечить корректность проекта, прежде чем тратить огромные усилия на его реализацию и тестирование?

Не думаю, что мы обнаружим здесь чудеса. Верификация программ является очень мощной концепцией, и она очень важна для таких вещей, как создание надежного ядра операционной системы. Эта технология не обещает, однако, экономии труда.

Верификация требует столько работы, что весьма немногие значительные программы вообще были верифицированы.

Верификация программ не означает создания программ, лишенных ошибок. И здесь нет чудес. Математические доказательства тоже могут быть ошибочными. Поэтому хотя верификация может облегчить тестирование, она не может отменить его.

Более существенно, что даже самая совершенная верификация программы может лишь определить, что программа отвечает своим спецификациям. Самая сложная задача программирования — получить полную и непротиворечивую спецификацию, и сущность создания программы на практике во многом состоит в отладке спецификации.

Среды программирования и инструменты. Какого еще выигрыша можно ожидать от стремительно расширяющихся исследований по усовершенствованию сред программирования? Инстинктивно кажется, что задачи, которые сулили наибольшую отдачу, были в числе первых, за которые взялись, и их уже решили: иерархические файловые системы, единообразные форматы файлов для получения единообразных программных интерфейсов и обобщенных инструментов. Ориентированные на конкретные языки интеллектуальные редакторы пока не очень распространены, но большее, на что они способны, это устранение синтаксических ошибок и мелких семантических.

Возможно, наибольший выигрыш среда программирования сможет дать при использовании строенных систем баз данных для отслеживания мириадов деталей, которые каждый программист должен точно вспоминать, и которые должны храниться в текущем состоянии в группе работающих над одной системой.

Несомненно, что это работа заслуживает внимания и принесет некоторые плоды как для производительности, так и для надежности. Но ввиду самой ее сути отдача должна быть незначительной.

Рабочие станции. Какой выигрыш может получить искусство программирования от несомненного и быстрого роста мощности и объема памяти отдельной рабочей станции? Сколько миллионов операций в секунду можно плодотворно использовать?

Составление и редактирование программ вполне обеспечиваются сегодняшними скоростями. Компиляция может быть ускорена, но десятикратное увеличение скорости машины, вне сомнения, сделает обдумывание основным занятием программиста в течение рабочего дня. Пожалуй, это так уже сейчас.

Конечно, мы приветствуем увеличение мощности рабочих станций. Но рассчитывать на связанные с этим чудеса мы не можем.

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

Все технологические подходы к акциденциям процесса программирования принципиально ограничены уравнением продуктивности:

Время _ решения _ задачи = i (Частот) (Длительность)i i Если, как я полагаю, концептуальные составляющие задачи сейчас отнимают большую часть времени, то никакая работа над составными частями задачи, являющимися просто выражением концепций, не даст большого выигрыша.

Поэтому мы должны рассмотреть те направления, которые затрагивают саму сущность проблемы программирования — формулировку этих сложных концептуальных структур. К счастью, некоторые из этих направлений весьма многообещающи.

Покупать, а не создавать. Наиболее радикальное возможное решение при создании программ — вообще не создавать их.

С каждым днем это становится все легче, поскольку все большее число поставщиков предлагает все более многочисленные и лучшие программные продукты для немыслимого разнообразия приложений. Пока мы, инженеры-программисты, трудились над совершенствованием методологии производства, революция, произведенная персональными компьютерами, создала не один, а много массовых рынков программного обеспечения. В каждом газетном киоске выставлены ежемесячные журналы, в которых, отсортированные по типам машин, рекламируются и рецензируются десятки продуктов по ценам от нескольких долларов до нескольких сотен долларов. Более специализированные издания предлагают очень мощные продукты для рабочих станций и других рынков Unix.

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

Любой такой продукт дешевле купить, чем создавать заново. Даже при цене 100 долларов купленный продукт стоит примерно столько, сколько годовое содержание программиста. И поставка немедленная! Немедленная, по крайней мере, для реально существующих продуктов, проспект которых разработчик может послать счастливому пользователю. Более того, такие продукты обычно гораздо лучше документированы и несколько лучше сопровождаются, чем доморощенные программы.

Развитие массового рынка является, по моему мнению, наиболее глубокой долгосрочной тенденцией программной инженерии. Стоимость программного продукта всегда определялась стоимостью разработки, а не тиражирования.

Разделив эту стоимость даже на нескольких пользователей, мы коренным образом снижаем цену на одного пользователя. Взглянув на это с другой стороны, мы видим, что использование n копий программной системы фактически умножает на n производительность его разработчиков. Это рост производительности отрасли и всей страны.

Главным вопросом, конечно, является производительность. Смогу ли я использовать имеющийся коробочный продукт для решения своих задач? Здесь случилась удивительная вещь. В 50-х и 60-х годах одно исследование за другим показывало, что пользователи не хотят использовать коробочные пакеты для расчета зарплаты, управления складом, учета дебиторов по расчетам и т.д. Требования были слишком специальными, отклонения от случая к случаю слишком большими. В 80-х годах мы обнаруживаем большой спрос на такие пакеты и широкое их использование. Что изменилось?

Только не пакеты. Они стали несколько более общими и лучше настраиваются, чем раньше, но не намного. И не область их применения. В конце концов, сегодня потребности бизнеса и науки более разнообразны и сложны, чем 20 лет назад.

Резко изменилось соотношение стоимости компьютеров и программ. Тот, кто в году покупал машину за 2 миллиона долларов, считал, что может позволить себе потратить еще 250 000 долларов на заказную программу расчета зарплаты, которая легко и без ущерба вписалась бы во враждебную компьютерам социальную среду.

Те, кто сегодня покупают машину для офиса за 50 000 долларов, не могут, понятно, позволить себе заказные программы расчета зарплаты, поэтому они приспосабливают свои процедуры расчета зарплаты к имеющимся пакетам.

Компьютеры сейчас столь обычны, если не столь любимы, что адаптация воспринимается как обычное дело.

Есть яркие исключения из моего утверждения о том, что обобщенность программных пакетов за последние годы мало изменилась: электронные таблицы и простые системы баз данных. Эти мощные инструменты, столь очевидные задним умом и так поздно появившиеся, имеют бесчисленное множество применений, в том числе, весьма необычные. Есть масса статей и даже книг о том, как с помощью электронной таблицы решать неожиданные задачи. Большое число задач, для которых раньше были бы написаны заказные программы на Cobol или Report Program Generator, теперь шаблонно решается с помощью этих инструментов.

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

Я считаю, что сегодня для многих организаций самая правильная политика для повышения производительности разработки программного обеспечения — это установить своим не имеющим компьютерных знаний работникам умственного труда компьютеры и хорошие общие программы для обработки текстов, рисования, работы с файлами и электронными таблицами и отпустить их в вольное плавание. Такая же политика в отношении распространенных математических и статистических пакетов, а также некоторых навыков программирования подойдет сотням ученых, работающих в лабораториях.

Уточнение требований и быстрое макетирование. Самая трудная отдельная задача в разработке программной системы — это точно решить, что разрабатывать.

Ни одна другая задача работы над концепциями не является столь трудной, как разработка подробных технических требований, включая все интерфейсы пользователей, машинные интерфейсы и интерфейсы к другим программным системам. Ни одна другая часть работы не наносит такого ущерба готовой системе, если сделана неправильно. Ни одна другая часть не исправляется позднее с бльшим трудом.

Поэтому наиболее важной функцией, осуществляемой разработчиками для своих клиентов, является повторяющееся получение и уточнение требований к продукту.

Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумывались над задачей настолько детально, как это нужно указать в спецификации. Даже простой ответ — «сделайте так, чтобы новая программная система работала так, как наша старая ручная система обработки информации» — оказывается в действительности слишком упрощенным. Клиенты никогда не хотят этого в точности. Более того, сложные программные системы действуют, движутся, работают. Динамику этого действия трудно себе представить. Поэтому при планировании любых действий необходимо оставить резерв для многократного взаимодействия между клиентом и проектировщиком при описании системы.

Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют.

Поэтому одним из наиболее многообещающих современных направлений в технологии, причем обращенных к сущности, а не к акциденциям проблем программирования, является разработка подходов и инструментов для быстрого создания макетов систем как части итеративного процесса разработки спецификаций.

Макет программной системы моделирует главные интерфейсы и выполняет основные функции предполагаемой системы, при этом не обязательно будучи связан теми же ограничениями быстродействия компьютера, размера или стоимости. Обычно макеты выполняют основные задачи системы, но не пытаются обрабатывать исключительные ситуации, правильно реагировать на ввод недопустимых данных, корректно прерывать работу и т.д. Назначение макета — показать, как воплощается выбранная концептуальная структура, чтобы клиент мог проверить ее пригодность к использованию и непротиворечивость.

Сегодня многие процедуры приобретения программного обеспечения основываются на предположении, что можно заранее задать технические требования для желаемой системы, рассмотреть предложения разработчиков, получить разработанную систему и установить ее. Я думаю, что такое предположение в корне неверно, и из-за этой ошибки проистекают многие проблемы при приобретении программ, поскольку эти проблемы нельзя устранить без пересмотра основ, для которого требуется интерактивная разработка и спецификации макетов и продуктов.

Пошаговая обработка: наращивать программу, а не строить сразу. Я до сих пор помню испытанный в 1958 году удар, когда впервые услышал, как мой друг говорил о строительстве (building) программ в противоположность написанию (writing). В мгновение он расширил все мое представление о процессе программирования.

Применение метафоры было сильным и точным. Сегодня мы понимаем, что сходство существует между созданием программы и другими строительными процессами, и свободно используем другие элементы метафоры, такие как спецификации (specifications), сборка компонентов (assembly of components), леса (scaffolding).

Метафора строительства пережила свое время. Пора снова вносить изменения. Если, как я считаю, создаваемые сегодня концептуальные структуры слишком сложны, чтобы их можно было точно специфицировать заранее, и слишком сложны, чтобы строить без ошибок, тогда нужен радикально иной подход.

Обратимся к природе и рассмотрим сложность живых созданий, а не безжизненных творений человека. Там мы обнаруживаем конструкции, сложность которых вселяет в нас ужас. Один только мозг настолько сложен, что невозможно составить его схему. Его мощь невозможно повторить, он богат своеобразием, способен к самосохранению и самообновлению. Секрет в том, что мозг растет, а не строится.

Так же должны создаваться наши программные системы. Несколько лет назад Харлан Миллз предложил наращивать программные системы путем пошаговой разработки.11 Это значит, что сначала систему надо заставить выполняться, даже если при этом она не делает ничего полезного, кроме вызова некоторого числа фиктивных подпрограмм. Затем она понемногу обрастает мясом, причем подпрограммы, в свою очередь, разрабатываются сначала как вызовы пустых фиктивных подпрограмм, находящихся на уровень ниже.

Настаивая на применении этой технологии разработчиками проектов на моих лабораторных занятиях по программной инженерии, я стал свидетелем поразительных результатов. За последнее десятилетие ничто другое не оказало столь сильного влияния на мою собственную работу и ее эффективность. Этот подход предполагает нисходящее проектирование, поскольку это — нисходящее наращивание программы. Он позволяет легко отслеживать работу в обратном направлении. Он предоставляет возможность раннего создания макетов. Каждая новая функция или возможность работы с более сложными данными или условиями органически вырастают на того, что уже имеется.

Воздействие на моральный дух ошеломительное. Когда есть хотя бы простая работающая система, возрастает энтузиазм. Энергия удваивается, когда на экране появляется картинка из новой графической программной системы, даже если это всего лишь прямоугольник. И на каждой стадии процесса разработки существует работающая система. Я считаю, что за одинаковые сроки команда может нарастить значительно более сложный объект, чем построить.

В больших проектах можно ощутить такие же выгоды, как и в моих маленьких. Выдающиеся проектировщики. Главная проблема совершенствования искусства программирования заключена, как всегда, в людях.

Мы можем добиваться хороших проектов, следуя хорошим, а не плохим практическим приемам. Хорошим приемам можно обучать. Программисты принадлежат к наиболее интеллектуальной части общества, следовательно, они в состоянии изучать хорошие приемы. Поэтому важнейшим направлением в Соединенных Штатах является распространение хороших современных приемов.

Новые курсы, новые издания, новые организации, такие как Институт инженеров программистов (Software Engineering Institute) — все это вызвано к жизни стремлением повысить уровень наших практических приемов. Это совершенно правильно.

Тем не менее, я считаю, что мы не сможем подняться еще на одну ступеньку выше, действуя в этом направлении. Выбор правильного метода проектирования определяет различия между плохим и хорошим концептуальным проектом, но не между хорошим и выдающимся. Выдающиеся проекты создаются выдающимися проектировщиками. Создание программ является творческим процессом. Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой.

И разница немалая — это как Сальери и Моцарт. Одно исследование за другим показывают, что лучшие проектировщики создают структуры, которые быстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями. Различия между выдающимся и средним достигают порядка величины.

Нетрудно проследить, что ряд хороших и полезных программных систем проектировался комиссиями и создавался с помощью проектов, состоявших из многих частей. Но программные системы, вызвавшие восхищение страстных поклонников, являются продуктом одного или небольшого числа выдающихся проектировщиков. Посмотрите на Unix, APL, Pascal, интерфейс Smalltalk и даже Fortran — с одной стороны, и Cobol, PL/I, Algol, MVS/370 и MS-DOS — с другой (рис.

16.1).

Да Нет Unix Cobol APL PL/I Pascal Algol Modula MVS/ Smalltalk MS-DOS Fortran Рис. 16.1 Имеются ли у этих продуктов страстные поклонники?

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

Ни одна занятая в программировании организация не может игнорировать эту проблему. Хороших менеджеров, как бы мало их ни было, не меньше, чем хороших проектировщиков. Как выдающиеся проектировщики, так и выдающиеся менеджеры встречаются редко. В большинстве организаций значительные усилия тратятся на поиска и выращивание подающих надежды менеджеров. Я не слышал, чтобы кто либо тратил такие же усилия на поиски и развитие выдающихся проектировщиков, от которых, в конечном счете, зависит техническое превосходство продуктов.

Первое мое предложение состоит в том, чтобы каждая занятая в программировании организация определила для себя и провозгласила, что выдающиеся проектировщики имеют для ее успеха такое же большое значение, как и выдающиеся менеджеры, и что они могут рассчитывать на такие же заботу и вознаграждение. Не только зарплата, но и атрибуты положения — размеры офиса, мебель, техническое оборудование, командировочные фонды, обеспеченность сотрудниками — должны быть полностью равнозначны.

Как растить выдающихся проектировщиков? Место не позволяет обсуждать это пространно, но вот некоторые очевидные шаги:

• Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие — не всегда самые опытные.

• Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.

• Разработать и осуществлять план служебного роста для каждого перспективного проектировщика, включающий тщательно продуманное обучение у передовых проектировщиков, периоды дополнительного формального обучения, краткосрочные курсы, перемежающиеся с самостоятельным проектированием и назначением на руководящие технические должности.

• Обеспечить возможности для взаимодействия и взаимного стимулирования растущих проектировщиков.

Глава 17 Новый выстрел «Серебряной пули нет» Глава 17 Новый выстрел «Серебряной пули нет» Глава 17 Новый выстрел «Серебряной пули нет» У всякой пули — свое предназначение.

ВИЛЬГЕЛЬМ III ОРАНСKИЙ Kто хочет увидеть образец совершенства, Тот мечтает о том, чего никогда не было, нет и не будет.

АЛЕKСАНДР ПОП, «О KРИТИKЕ» Об оборотнях и прочих мифических ужасах «Серебряной пули нет: сущность и акциденция в программной инженерии» (глава данной книги) первоначально была заказным докладом для конференции 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 доказывает, что даже организационная сложность, возможно, не является произвольной, а может испытывать воздействие принципов упорядочения:

Я получил образование в облати физики и поэтому вижу, что «сложные» вещи могут быть описаны на языке более простых понятий. Вы можете быть правы, и я не стану утверждать, что все сложные вещи поддаются принципам упорядочения... по тем же правилам доказательства нельзя утверждать, что не поддаются.

...То, что вчера было сложностью, завтра будет в порядке вещей. Сложность беспорядочного движения молекул привела к возникновению кинетической теории газов и открытию трех законов термодинамики. Сейчас программное обеспечение не позволяет увидеть присущие ему принципы упорядочения, но вы как раз и должны объяснить, почему это происходит. Это не проявление моей бестолковости или желания поспорить. Я убежден, что в один прекрасный день «сложность» программного обеспечения будет объяснена на языке каких нибудь понятий более высокого порядка (инвариантов, как говорят физики).

Я не занимался более глубоким анализом, к которому справедливо призывает Лукашик. Как отрасль науки мы нуждаемся в развитии теории информации для количественной оценки информационного содержания статистических структур, подобно тому, как теория Шэннона делает это для информационных потоков. Это совсем не моя задача. Лукашику я просто отвечу, что сложность системы является функцией мириадов деталей, каждая из которых должна быть точно задана либо с помощью какого-нибудь общего правила, либо подробным описанием, но не просто статистически. Представляется весьма сомнительным, чтобы несогласованные результаты работы многих голов оказались достаточно связными, чтобы быть точно описанными общими правилами.

Значительно большая часть сложности программных конструкций обусловлена, однако, не соответствием внешнему миру, а самой реализацией — структурами данных, алгоритмами, способами коммуникаций. Наращивание программ с помощью больших блоков высокого уровня, созданных когда-то раньше или кем-то другим, помогает избежать целых уровней сложности. «СПН» провозглашает поход на проблему сложности в полной надежде, что можно достичь прогресса. Она выступает за добавление к программной системе необходимой сложности:

• иерархически, располагая модули или объекты по уровням;

• пошагово, что обеспечивает постоянную работоспособность системы.

Анализ Харела Дэвид Харел (David Harel) в статье 1992 года «Кусая серебрянную пулю» предпринимает самый тщательный анализ «СПН» из всех опубликованных. Пессимизм против оптимизма и реализма. Харел рассматривает как «СПН», так и статью Парнаса 1984 года «Программные аспекты стратегических оборонительных систем»10 как «слишком унылые». Он намеревается высветить более яркую сторону проблемы, предпосылая статье подзаголовок «К светлому будущему порграммных разработок». Так же, как и Кокс, Харел считает «СПН» пессимистической, говоря:

«Если взглянуть на те же факты с другой точки зрения, возникают более оптимистические выводы». Оба они неправильно воприняли тональность статьи.

Прежде всего, моя жена, коллеги и редакторы считают, что я гораздо чаще впадаю в неоправданный оптимизм, чем в пессимизм. В конце концов я по происхождению программист, а оптимизм — это профессиональная болезнь данного ремесла.

В «СПН» прямо сказано: «Вглядываясь в предстоящее десятилетие, мы не видим серебряной пули... Однако скептицизм не есть пессимизм... Нет царского пути, но путь есть». Она предсказывает, что нововведения, происходящие в 1986 году, будучи разработаны и использованы, в совокупности действительно позволят достичь роста производительности на порядок. Десятилетие 1986-1996 подходит к концу, и это предсказание оказывается, скорее, слишком оптимистичным, а не мрачным.

Даже если бы все без исключения считали «СПН» пессимистической, что в этом худого? Является ли утверждение Эйнштейна о том, что ничего не может перемещаться со скоростью, большей скорости света, «унылым» и «мрачным»? А как насчет результатов Геделя о том, что некоторые вещи невычислимы? «СПН» пытается утверждать, что «сама сущность программного обеспечения делает маловероятным открытие «серебряных пуль» когда-либо в будущем». Турский в своем отличном ответном докладе на конференции IFIP красноречиво заявил:

Из всех попыток науки продвинуться в ложном направлении наиболее возвышенны те, которые были направлены на поиск философского камня — вещества, с помощью которого предполагалось обращать простые металлы в золото. Высшая цель алхимии, к которой с рвением стремились поколения исследователей, щедро финансировавшиеся светскими и духовными правителями, — это в чистом виде стремление принимать желаемое за действительное и общепринятое мнение, что вещи таковы, какими мы хотели бы их видеть. Это очень по-человечески. Нужно сделать над собой большое усилие, чтобы смириться с существованием неразрешимых проблем.

Стремление вопреки всему найти выход, даже когда доказано, что его не существует, очень и очень сильно. И в большинстве своем мы с большим сочувствием относимся к этим храбрецам, которые пытаются достичь невозможного. Это продолжается и по сей день. Пишутся сочинения о квадратуре круга. Стряпаются лосьоны для восстановления утраченных волос — и неплохо продаются. Рождаются методы повышения производительности программирования — и хорошо расходятся.

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

«Мрачные» темы. Харел считает, что мрачность «СПН» придают три темы:

• Резкое разделение между сущностью и второстепенным.

• Изолированное рассмотрение каждого кандидата в «серебряные пули».

• Прогноз лишь на ближайшие 10 лет, а не на срок, в течение которого можно ожидать «существенных улучшений».

Что касается первого, то в это вся соль статьи. Я по-прежнему считаю, что такое разделение необходимо для понимания того, почему трудно создавать программное обеспечение. И это верное указание, куда должен быть направлен удар.

Что касается изолированного рассмотрения кандидатов в «серебряные пули», то это правда. Разные кандидаты предлагались поочередно и непомерными претензиями на собственное всесилие. Правомерно и рассматривать их поочередно. Я возражаю не против самих технологий, но против ожидания от них чуда. Гласс, Весси и Конджер (Glass, Vessey, Conger) в своей статье 1992 года представили многочисленные свидетельства того, что бесполезные поиски серебряной пули все еще продолжаются. Что касается выбора в качестве периода предсказаний 10, а не 40 лет, то частично это признание того, что наши предсказания на больший срок никогда не были удачными. Кто из нас в 1975 году предсказал микрокомпьютерную революцию 80-х?

Есть и другие причины ограничиться десятилетием: все кандидаты претендовали на получение результатов немедленно. Я не помню ни одного, который бы сказал:

«Если сегодня вы сделаете инвестиции в предлагаемое мной средство, то по прошествии 10 лет начнете пожинать плоды». Более того, за десятилетие соотношение производительность/цена для компьютеров выросло, наверное, в сотни раз, и неизбежно подсознательно производится сравнение, которое совершенно недопустимо. Мы наверняка достигнем большего прогресса за предстоящие 40 лет.

Рост за 40 лет на порядок едва ли покажется чудом.

Мысленный эксперимент Харела. Харел предлагает мысленный эксперимент, в котором «СПН» была написана в 1952 году, а не в 1986, но содержала бы те же утверждения. Он хочет использовать это в качестве доказательства от противного в борьбе против попыток отделить сущность от акциденции.

Это доказательство неверно. Во-первых, «СПН» начинается с утверждения, что для программирования в 1950-х характерно значительное преобладание трудностей в акциденциях над трудностями в сущности. Этого преобладания больше не существует, что привело к росту производительности на порядки величин.

Переносить это доказательство на 40 лет назад бессмысленно: никто не стал бы в 1952 году утверждать, что не трудности акциденций ответственны за большую часть затрачиваемых усилий.

Во-вторых, Харел неточно представляет положение дел в 1950-х:

Это было время, когда вместо того, чтобы разрабатывать большие сложные системы, программисты писали обычные однопользовтельские программы, которые на современных языках программирования заняли бы 100-200 строк, и которые должны были выполнять скромные алгоритмические задачи. При существовавших тогда технологиях и методологиях такие задачи тоже были очень трудными. Сплошь и рядом были неудачи, ошибки, нарушение сроков.

Затем он описывает, как за последние 25 лет упомянутые неудачи, ошибки, нарушенные сроки в обычных маленьких одновользовательских программах были улучшены на порядок.

Но в действительности в 1950-х годах вершиной технологии были не маленькие однопользовательские программы. В 1952 году Univac был занят обработкой данных переписи 1950 года с помощью сложной программы, которую разрабатывали примерно восемь программистов.13 Другие машины применялись в химической динамике, расчетах рассеяния нейтронов, расчетах полета ракет и т.д. Повседневно использовались ассемблеры, перемещающие компоновщики и загрузчики, системы интерпретации с плавающей точкой и т.п. К 1955 году уже создавались программы для бизнеса объемом от 50 до человеко-лет.16 В 1956 году на заводе Дженерал Электрик в Льюисвилле работала программа размером более 80 000 слов. В 1957 году в течение уже двух лет в системе противовоздушной обороны работал компьютер SAGE ANFSQ/7, и на площадках действовала система реального времени, использовавшая телекоммуникации и дублирование в целях отказоустойчивости, объемом 75 команд.17 Едва ли можно придерживаться мнения, что развитие технологий для однопользовательских программ — главная характеристика усилий в технике программного обеспечения после 1952 года.

ВОТ ОНА. Харел продолжает, предлагая собственную серебряную пулю, технологию моделирования под названием «Vanilla Framework» («ванильная структура»). Сам подход описан недостаточно подробно, чтобы его можно было оченить, но есть ссылка на статью и технический отчет, который в свое время должен быть опубликован в виде книги.18 Моделирование касается сущности, правильной разработки и отладки понятий, поэтому технология может оказаться революционной.

Надеюсь, что это так. Кен Брукс сообщает, что эта методология оказалась полезной, когда он попытался применить ее к реальной задаче.

Незримость. Харел энергично доказывает, что значительная часть концептуальной конструкции программного обеспечения является по своей природе топологической задачей, и эти взаимосвязи находят соответствие в пространственно-графических представлениях:

Использование подходящего визуального формализма может оказать заметное воздействие на инженеров и программистов. Более того, это воздействие не ограничивается областью акциденций, было обнаружено положительное влияние на качество и быстроту самого их мышления. В будущем успехи в разработке систем будут связаны с визуальными представлениями. Сначала мы будем создавать концепции с помощью «правильных» объектов и взаимосвязей, затем формулировать наши концепции как последовательный ряд все более обстоятельных моделей с использованием подходящей комбинации визуальных языков. Именно комбинации, поскольку модели систем имеют несколько граней, каждая из которых вызывает в воображении различные виды образов.

...Некоторые грани процесса моделирования не столь легко поддаются хорошей визуализации. Например, алгоритмические операции над переменными и структурами данных, возможно, останутся текстуальными.

Здесь наши позиции близки. Я доказывал, что структура программного обеспечения не является трехмерной, поэтому не существует естественного отображения концептуального проекта в диаграмму в пространстве как двух, так и большего числа измерений. Харел допускает, и я согласен, что требуется много диаграмм, каждая из которых охватывает какую-то одну сторону, а некоторые аспекты вообще плохо отображаются на диаграммах.

Я вполне разделяю его энтузиазм по поводу использования диаграмм как вспомогательного средства при обдумывании и проектировании. Долгое время я любил задавать кандидатам на работу программистом вопрос: «Где находится следующий ноябрь?». Если вопрос кажется загадочным, то в другом виде: «Какова ваша мысленная мысленная модель календаря?» У действительно хороших программистов хорошее чувство пространства, у них обычно есть геометрическая модель времени, и они часто без труда понимают первый вопрос. Их модели очень индивидуальны.

Точка зрения Джонса: происзводительность приходит вслед за качеством Каперс Джонс (Capers Jones) сначала в серии служебных записок, а затем в отдельной книге демонстрирует глубокую интуицию, отмеченную несколькими моими корреспондентами. «Статья «СПН», как и многие в то время, сосредоточилась на производительности — выходе программной продукции на единицу входных затрат», — говорит Джонс. — «Нет, сосредоточьтесь на качестве, а производительность придет следом.»19 Он утверждает, что дорогостоящие и нарушившие сроки проекты требуют больше всего дополнительных усилий и времени для поиска и устранения ошибок в спецификациях, в проекте, в разработке.

Он приводит данные, свидетельствующие о сильной корреляции между отсутствием систематического контроля качества и срывом графика работ. Я им вполне верю.

Бём (Boehm) указывает, что производительность снова падает, когда преследуется исключительно высокое качество, как было в программах IBM для космического челнока.

Аналогичным образом, Коки (Coqui) утверждает, что принципы систематической разработки программного обеспечения явились ответом на озабоченность не столько производительностью, сколько качеством (в особенности, стремлением избежать крупных катастроф).

Но обратите внимание: целью применения инженерных принципов к разработке программного обеспечения в 1970-х годах было поднять качество, тестируемость, устойчивость и предсказуемость программных продуктов, а не обязательно производительность труда программистов.

Движущей силой использования при разработке программ принципов программной инженерии было опасение крупных аварий, к которым могла привести разработка все более сложных систем неуправляемыми художниками. Так что же случилось с производительностью?

Производительность в цифах. Цифры, характеризующие производительность, очень тяжело определить, калибровать и найти. Каперс Джонс считает, что для двух одинаковых программ на Cobol, написанных с интервалом в 10 лет — с применением структурного программирования и без него — разница в производительности троекратная.

Эд Йордон (Ed Yourdin) утверждает: «По моим наблюдениям, благодаря рабочим станциям и программным инструментам производительность увеличилась в пять раз.» Том Демарко (Tom DeMarco) считает, что «ваше ожидание десятикратного роста производительности за 10 лет благодаря целому набору технологий было оптимистичным: мне неизвестны организации, добившиеся роста производительности на порядок.» Программа в упаковке: покупайте, не надо разрабатывать. Одна из оценок «СПН» оказалась, я думаю, правильной: «Возникновение массового рынка является... наиболее глубокой долгосрочной тенденцией в разработке программного обеспечения». С точки зрения науки, программное обеспечение для массового рынка образует практически новую отрасль в сравнении с разработкой заказных программ как внутри фирмы, так и сторонними организациями. Когда счет проданных пакетов идет на миллионы или хотя бы на тысячи, главными проблемами становятся качество, своевременность, технические характеристики и стоимость поддержки, а не стоимость разработки, которая имеет такое большое значение при разработке заказных систем.

Электроинструмент для ума. Лучший способ повысить производительность труда программистов информационно-управляющих систем — это пойти в ближайший компьютерный магазин и купить уже готовым то, что они собираются разработать.

Это не шутка: доступность дешевых и мощных коробочных программ удовлетворила многие из потребностей, ранее удовлетворявшихся заказными программами. Эти электроинструменты для ума больше похожи на электрическте дрели, пилы и шлифовальные машины, чем на большие и сложные производственные станки.

Интеграция их в совместимые и перекрестно-связанные наборы, такие как Microsoft Works или лучше интегрированный ClarisWorks, обеспечивает огромную гибкость. И подобно домашней коллекции инструмента, в результате частого использования набольшого набора для разных задач вырабатываются привычные навыки. Такой инструмент подчеркивает простоту использования обычным пользователем, даже не профессионалом.

Иван Селин (Ivan Selin), глава American Management Systems писал мне в 1987 году:

Я хочу придраться к вашему утверждению, что в действительности пакеты не настолько изменились... Я думаю, что вы слишком легко отбросили главные следствия вашего замечания, что (программные пакеты) «могут быть немного более общими и немного лучше настраиваемыми, чем раньше, но не намного».

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

Я думаю, что Селин совершенно прав: я недооценил как степень настраиваемости пакета, так и важность этого фактора.

Объектно-ориентированное программирование: а медна пуля не подойдет?

Разработка из больших частей. Если осуществлять сборку из частей, которые достаточно сложны и имеют однородные интерфейсы, можно быстро образовывать довольно богатые структуры.

Согласно одному из взглядов на объектно-ориентированное программирование эта дисциплина осуществляет модульность и чистые интерфейсы. Другая точка зрения подчеркивает инкапсуляцию — невозможность увидеть и еще менее изменить внутреннюю структуру детали. Еще одна точка зрения отмечает наследование и сопутствующую ему иерархическую структуру классов с виртуальными функциями. И еще один взгляд: важнейшей является сильная абстрактная типизация данных вместе с гарантиями, что конкретный тип данных будет обрабатываться только применимыми к нему операциями.

В настоящее время не нужен весь пакет Smalltalk или C++, чтобы использовать любой из этих дисциплин — многие из них поглотили объектно-ориентированные технологии. Объектно-ориентированный подход привлекателен, как поливитамины:

одним махом (т.е. переподготовкой программиста) получаешь все. Очень многообещающая концепция.

Почему объектно-ориентированная технология медленно развивалась? В течение девяти лет после выхода «СПН» надежды неуклонно росли. Почему развитие было таким медленным? Теорий много. Джеймс Коггинс, в течение четырех лет ведущий колонку в The C++ Report, дает такое объяснение:

Проблема в том, что программисты, работающие в ООП, экспериментировали с кровосмесительными приложениями и были нацелены на низкий уровень абстракции. Например, они строили такие классы, как «связанный список» вместо «интерфейс пользователя», или «луч радиации», или «модель из конечных элементов». К несчастью, строгая проверка типов, которая помогает программистам C++ избегать ошибок, одновременно затрудняет построение больших объектов из маленьких. Он возвращается к фундаментальной проблеме программирования и доказывает, что один из способов удовлетворить потребность в программном обеспечении — увеличить численность образованной рабочей силы путем подготовки и привлечения наших клиентов. В пользу нисходящего проектирования приводятся такие аргументы:

Если мы проектируем крупные классы, представляющие концепции, с которыми наши клиенты уже работают, то они в состоянии понимать и критиковать проект по мере его развития, а также вместе с нами разрабатывать контрольные примеры. Офтальмологов, с которыми я работаю, не волнует организация стека;

их волнует описание формы роговицы с помощью полиномов Лежандра. Маленькая инкапсуляция дает и маленькую выгоду.

Дэвид Парнас, чья статья была одним из источников идей объектно ориентированного программирования, смотрят на вещи по иному. Он писал мне:

Ответ прост. Это из-за привязанности ООП к сложным языкам. Вместо объяснения людям, что ООП является видом проектирования, и вооружения их принципами проектирования, их учили, что ООП — это использование определенного инструмента. Любыми срадствами можно писать и плохие, и хорошие программы. Если не учить людей проектированию, то языки не имеют большого значения. Результатом будут плохие разработки с помощью этих языков и малая выгода. А если выгода невелика, то ООП не войдет в моду.

Расходы сейчас, прибыль потом. По моему мнению, у объектно-ориентированных методологий особенно тяжелый случай болезни, характерной для многих усовершенствований в методологии. Весьма существенны предварительные издержки — в основном, чтобы научить программистов мыслить совершенно по новому, а также на преобразование функций в обобщенные классы. Выгоды, которые я считаю реальными, а не чисто предположительными, достигаются во время всего цикла разработки, но настоящая окупаемость происходит при разработке последующих программ, расширении и сопровождении. Коггинс коворит:

«Объектно-ориентированное программирование не ускорит разработку первого проекта, так же как и второго. А вот пятый проект из того же семейства будет сделан очень быстро.» Рисковать реальными начальными деньгами ради предполагаемых, но неопределенных прибылей в будущем — это то, чем инвесторы занимаются изо дня в день. Однако во многих программирующих организациях менеджерам требуется для этого смелость — качество более редкое, чем компетенция в технических вопросах или административное мастерство. Я полагаю, что крайняя степень авансироания расходов и откладывания прибыли является самым существенным фактором, замедляющим принятие О-О технологий. Но даже в таких условиях C++, похоже, уверенно вытесняет C во многих организациях.

Что с повторным использованием?

Лучший способ справиться с разработкой части программной системы, относящейся к ее сущности — это вообще ее не разрабатывать. Пакеты программ — один из способов сделать это. Другой способ — повторное использование. Действительно, одной из наиболее привлекательных черт объектно-ориентированного программирования является обещание простоты повторного использования классов в сочетании с легкостью настройки благодаря наследованию.

Как часто бывает, после получения некоторого опыта работы по новой технологии обнаруживается, что она не так проста, как казалось на первый взгляд.

Конечно, программисты всегда повторно использовали собственные разработки.

Джонс пишет:

У наиболее опытных программистов есть свои личные библиотеки, позволяющие им при разработке новых программ повторно использовать до 30% кода по объему. На корпоративном уровне повторное использование приближается к 75% по объему и требует специальных библиотек и администрирования. Повторное использование кода в корпоративных масштабах требует изменений в бухгалтерии проекта и методах измерения работы. У. Хуан (W. Huang) предложил организацию программного производства с матричной структурой управления функциональными специалистами, чтобы держать под контролем их естественную склонность к повторному использованию собственного кода. Ван Шнайдер (Van Snyder) из JPL напоминает мне, что в кругах разработчиков математического программного обеспечения существует давняя традиция повторного использования программ:

Мы полагаем, что препятствия к повторному использованию возникают не со стороны производителя, а со стороны потребителя. Если разработчик программного обеспечения — потенциальный потребитель стандартных программных компонентов — считает, что найти и проверить нужный компонент дороже, чем написать его заново, значит, будет написан новый компонент, дублирующий прежний. Обратите внимание, мы сказали «считает» — реальная стоимость повторной разработки не имеет значения.

Повторное использование кода имеет успех при разработке математических программ. Причин этому две: 1) это магия, требующая огромного интеллектуального вклада в каждую строчку кода, и 2) существует богатая и стандартная терминология, а именно — математика, для описания функциональности любых компонентов. Поэтому повторно разработать математический компонент стоит дорого, а разобраться в функциональности стоит дешево. Давняя традиция публикации и сбора алгоритмов профессиональными журналами и предложения их по умеренной цене, а также коммерческое предложение высококачественных алгоритмов по несколько более высокой, но все же скромной цене, делают поиск требуемых компонентов проще, чем в других областях, где часто невозможно точно и сжато описать требуемое. Благодаря совместному действию этих факторов повторное использование математических программ более привлекательно, чем повторное их изобретение.

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

Каждое из этих сообществ выросло на одних и тех же учебниках, с одной и той же системой обозначений.

Как сегодня обстоят дела с повторным использованием на корпоративном уровне? Проведено множество исследований, а вот практикуется в США относительно мало. Что же касается повторного использования за рубежом, то тут имеют место неправдоподобные отчеты. Джонс сообщает, что все клиенты его фирмы, у которых более 5000 программистов, проводят формальные исследования повторной используемости, в то время как из числа клиентов с 500 и менее программстами это делает менее 10 процентов.26 По его сообщению, в отраслях с высоким потенциалом повторного использования исследования (не реализация) «ведутся активно и энергично, даже если не вполне успешно». Эд Йордон сообщает о программной фирме в Маниле, в которой программистов из общего числа 200 заняты только разработкой повторно используемых модулей для использования всеми остальными, и что в тех случаях, которые он видел, принятие этой технологии было вызвано организационными, а не техническими факторами — например, системой поощрений.

Демарко сообщает мне, что наличие массовых рыночных пакетов и возможность предоставления ими общих функций, таких как системы баз данных, существенно снизили как настоятельность, так и предельную полезность повторного использования модулей собственных приложений. «Повторно используемые модули имели тенденцию в конце концов становиться общими функциями.» Парнас пишет следующее:

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

Кен Брукс сообщает, что трудно рассчитать, какая степень обобщенности окажется необходимой: «Мне приходится менять вещи, даже в пятый раз используя собственную библиотеку пользовательских интерфейсов.» Реально повторное использование только начинается. Джонс сообщает, что на открытом рынке есть несколько модулей с повторно используемым кодом по цене от 1 до 20 процентов от обычной стоимости разработки.27 Демарко говорит:

Меня все более обескураживает вся эта история с повторным использованием.

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

Йордон дает оценку того, сколько это стоит: «Хорошее эмпирическое правило говорит, что повторно используемые компоненты потребуют вдвое больших затрат, чем «одноразовые» компоненты.»28 Я рассматриваю эту цену как величину затрат на запуск компонентов в производство, обсуждавшуюся в главе 1, поэтому я оцениваю рост затрат как троекратный.

Конечно, мы видим различные формы и варианты повторного использования, но оно далеко не так широко применяется, как мы предполагали. Предстоит еще многое понять.

Понимание больших словарей: неожиданная проблема повторного использования, которую можно было предвидеть Чем выше уровень, на котором осуществляется мышление, тем более многочисленны примитивные составляющие мысли, с которыми приходится иметь дело. Так, языки высокого уровня гораздо сложнее машинных языков, а естественные языки еще более сложны. У языков высокого уровня больше словари, более сложный синтаксис и более строгая семантика.

Как научная дисциплина, мы не взвесили последствия этого факта для повторного использования программ. Чтобы повысить качество и производительность, мы хотим строить программы из частей с отлаженными функциями, которые существенно выше по уровню, чем операторы языков программирования. Поэтому, делаем ли мы это с помощью библиотек классов или библиотек процедур, нам придется столкнуться с резким увеличением размеров наших словарей программирования. Изучение словаря составляет значительную часть препятствий к повторному использованию.

На сегодняшний день есть библиотеки классов, насчитывающие свыше 3000 членов.

Многие объекты требуют задания от 10 до 20 параметров и переменных переключателей. Всякий, использующий такую библиотеку, должен изучить синтаксис (внешние интерфейсы) и семантику (подробное поведение функции) ее членов, если собирается полностью реализовать потенциал повторного использования.

Эта задача вовсе не безнадежна. Обычно человек использует около 10000 слов родного языка, образованные люди — значительно больше. Каким-то образом мы обучаемся синтаксису и тонким семантическим различиям. Мы правильно опеределяем различия между словами гигантский, огромный, пространный, колоссальный, громадный — никто не говорит о колоссальных пустынях и пространных слонах.

Нужны дополнительные исследования, чтобы можно было применить к проблеме повторного использования программ существующие знания о том, как люди овладевают языком. Некоторые выводы непосредственно очевидны:

• Обучение происходит в контексте предложения, поэтому нужно публиковать многочисленные примеры составных продуктов, а не просто библиотеки составляющих частей.

• Человек запоминает только правописание. Синтаксис и семантика изучаются постепенно, в контексте, путем применения.

• Человек группирует правила соединения слов в синтаксические классы, а не в совместимые подмножества объектов.

Чистый итог по пулям: положение прежнее Итак, мы возвращаемся к основам. Сложность — это то, чем мы занимаемся, и сложность — это то, что нас ограничивает. Р. Л. Гласс (R. L. Glass) писал в году, точно суммируя мои взгляды 1995 года:

Так что же в итоге сообщили нам Парнас и Брукс? Что разработка программ является концептуально сложным занятием. Что волшебные решения не лежат за каждым углом. Что занимающимся этим делом пора изучить достижения, имеющие эволюционный характер, а не ждать революцию и не надеяться на нее.

Некоторые считают это безрадостной картиной. Это те, кто полагал, что вот-вот наступит прорыв.

Но некоторые из нас — достаточно сварливые, чтобы считать себя реалистами, — относятся к этому как к глотку свежего воздуха. Наконец-то можно сосредоточиться на чем-то более близком к жизни, чем журавль в небе.

Теперь, вероятно, мы сможем заняться постепенными усовершенствованиями производства программного обеспечения, которые действительно достижимы, а не ждать прорывов, которые вряд ли когда-либо произойдут. Глава 18 Заявления «Мифического человеко-месяца»: правда Глава 18 Заявления «Мифического человеко-месяца»: правда Глава 18 Заявления «Мифического человеко-месяца»: правда или ложь?

или ложь?

или ложь?

Kраткость очень полезна, Kогда нас понимают или не понимают.

СЭМЮЭЛ БАТЛЕР, «ГУДИБРАС» егодня о технике разработки программного обеспечения известно значительно Сбольше, чем в 1975 году. Какие из утверждений, содержащихся в первом издании 1975 года, подтвердились опытом и данными? Какие были опровергнуты? Какие устарели в нашем изменчивом мире? Чтобы вам легче было судить, здесь, в виде сводки, приведены важнейшие утверждения книги 1975 года, которые я считал верными: факты и извлеченные из опыта практические правила, приведенные с сохранением изначального смысла. (Можно задаться вопросом: если это все, что было сказано в первоначальном издании, почему тогда это заняло так много места?) В скобках приведены свежие комментарии.

Большинство этих предложений можно проверить на практике. Излагая их в сжатой форме, я надеюсь сконцентрировать мысли читателя, измерения и комментарии.

Глава 1. Смоляная яма 1.1 Для создания системного программного продукта требуется примерно в девять раз больше усилий по сравнению с составляющими его программами, написанными отдельно для частного использования. По моей оценке, превращение программы в продукт вводит коэффициент, равный трем;

проектирование, интеграция и тестирование компонентов, которые должны образовать согласованную систему, также вводит коэффициент, равный трем;

все эти составляющие стоимости существенно независимы друг от друга.

1.2 Занятие программированием «отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех у нас», доставляя пять видов радости:

• Радость, получаемая при создании чего-либо своими руками.

• Удовольствие создавать вещи, которые могут быть полезны другим людям.

• Очарование создания сложных головоломных объектов, состоящих из взаимодействующих движущихся частей.

• Радость, получаемая от неизменного узнавания нового, неповторяемости задачи.

• Удовольствие от работы со столь податливым материалом — чистой мыслью, который, тем не менее, существует, движется и работает так, как не могут словесные объекты.

1.3 В то же время этому занятию присущи и огорчения:

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

• Постановка задач осуществляется другими людьми и приходится зависеть от вещей (особенно, программ), которые нельзя контролировать;

полномочия не соответствуют ответственности.

• Страшно только на словах: фактическая власть приобретается как следствие успешного выполнения задач.

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

• Программному продукту грозит устаревание еще до его завершения.

Настоящий тигр — не пара бумажному, если требуется реальное использование.

Глава 2. Мифический человеко-месяц 2.1 Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам, вместе взятым.

2.2 Чтобы приготовить вкусную пищу, нужно время;

некоторые задачи нельзя ускорить, не испортив результат.

2.3 Все программисты являются оптимистами: «Все будет хорошо».

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

2.5 Но сами наши идеи бывают ошибочными — отсюда и ошибки в программах.

2.6 Наши методы оценивания, основанные на учете затрат, смешивают затраты с полученным результатом. Человеко-месяц является ошибочным и опасным заблуждением, поскольку предполагает, что месяцы и количество людей можно менять местами.

2.7 Разделение задачи между несколькими людьми вызывает дополнительные затраты на обучение и обмен информацией.

2.8 Мое практическое правило: 1/3 времени — на проектирование, 1/6 — на написание программы, 1/4 — на тестирование компонентов и 1/4 — на системное тестирование.

2.9 Как научной дисциплине нам не хватает методов оценки.

2.10 Поскольку мы не уверены в своих оценках сроков работы, нам часто не достает смелости упрямо отстаивать их под нажимом руководства и клиентов.

2.11 Закон Брукса: если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.

2.12 Добавление рабочей силы увеличивает общий объем затрат тремя путями:

труд по перекраиванию задач и происходящее при этом нарушение работы, обучение новых людей, дополнительное общение.

Глава 3. Операционная бригада 3.1 Самые лучшие программисты-профессионалы в 10 раз продуктивнее слабых при равной подготовке и двухлетнем стаже (Сакман, Грант и Эриксон).

3.2 Данные Сакмана, Гранта и Эриксона не выявили корреляции между опытом и продуктивностью. Я думаю, что это всегда так.

3.3 Лучше всего иметь маленькую активную команду — как можно меньше мыслителей.

3.4 Часто лучше всего, если команда состоит из двух человек, один из которых является лидером. (Обратите внимание, как Богом задуман брак.) 3.5 Для создания действительно крупных систем маленькая активная команда работает слишком медленно.

3.6 Опыт разработки большинства действительно больших систем показывает, что подход к ускорению с позиций грубой силы оказывается дорогостоящим, медленным, неэффективным и приводит к появлению систем, не являющихся концептуально целостными.

3.7 Организация по типу хирургических бригад с главным программистом предлагает способ достижения целостности продукта благодаря его проектированию в нескольких головах и общей продуктивности благодаря наличию многочисленных помощников при радикально сокращенном обмене информацией.

Глава 4. Аристократия, демократия и системное проектирование 4.1 «Концептуальная целостность является наиболее важным соображением при проектировании систем.» 4.2 «Окончательную оценку проекту системы дает отношение функциональности к сложности концепций», а не только богатство функций. (Это соотношение является мерой простоты использования, пригодной как для простого, так и для сложного использования.) 4.3 Для достижения концептуальной целостности проект должен создаваться одним человеком или группой единомышленников.

4.4 «Отделение разработки архитектуры от реализации является эффективным способом достижения концептуальной целостности при работе над очень большими проектами.» (И маленькими тоже.) 4.5 «Если вы хотите, чтобы система обладала концептуальной целостностью, кто то один должен взять руководство концепциями. Это аристократизм, который не нуждается в извинениях.» 4.6 Дисциплина полезна искусству. Получение архитектуры извне усиливает, а не подавляет творческую активность группы исполнителей.

4.7 Концептуально целостные системы быстрее разрабатываются и тестируются.

4.8 Проектирование архитектуры, разработку и реализацию можно в значительной мере осуществлять параллельно. (Проектирование аппаратного и программного обеспечения тоже могут проходить параллельно.) Глава 5. Эффект второй системы 5.1 Связь, установленная на ранних этапах и продолжающаяся непрерывно, может дать архитектору верную оценку стоимости, а разработчику — уверенность в проекте, не снимая при этом четкого разграничения сфер ответственности.

5.2 Как архитектору успешно влиять на реализацию:

• Помнить, что ответственность за творчество, проявляемое при реализации, несет строитель, поэтому архитектор только предлагает.

• Всегда быть готовым предложить некоторый способ реализации своих замыслов и быть готовым согласиться с любым другим способом, который не хуже.

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

• Не рассчитывать на признательность за предложенные усовершенствования.

• Выслушивать предложения разработчиков по усовершенствованию архитектуры.

5.3 Из всех проектируемых систем наибольшую опасность представляет вторая по счету;

обычно ее приходится перепроектировать заново.

5.4 OS/360 является ярким примером эффекта второй системы. (Похоже, что Windows NT — это пример для 1990 года.) 5.5 Достойной внимания практикой является предварительное назначение функциям величин в байтах и микросекундах.

Глава 6. Донести слово 6.1 Даже в большой команде проектировщиков оформление результатов нужно поручить одному или двум людям, чтобы обеспечить согласованность мини решений.

6.2 Важно явно определить те части архитектуры, которые не прописаны столь же тщательно, как остальные.

6.3 Необходимо иметь как формальное описание проекта — для точности, так и текстуальное — для понимания.

6.4 Либо формальное, либо текстуальное определения выбираются в качестве стандарта, при этом второе определение является производным. Каждое определение может выступать в любой из ролей.

6.5 Реализация, в том числе модель, может служить определением архитектуры;

такое использование имеет существенные недостатки.

6.6 Прямое включение является очень искусным приемом для осуществления стандартов архитектуры в программном обеспечении (в аппаратном обеспечении — тоже: возьмите интерфейс Mac WIMP, встроенный в ROM).

6.7 Архитектурное «определение будет яснее, а (архитектурная) дисциплина крепче, если изначально строятся как минимум две реализации».

6.8 Важно, чтобы архитектор в телефонных разговорах отвечал исполнителям на их вопросы;

обязательно нужно регистрировать эти разговоры в журнале и доводить их до общего сведения. (Сейчас для этого предпочтительнее электронная почта.) 6.9 «Лучший друг менеджера проекта — его постоянный противник, независимая организация, тестирующая продукт.» Глава 7. Почему не удалось построить Вавилонскую башню?

7.1 Проект Вавилонской башни провалился из-за недостатка обмена информацией и, как следствие, организации.

Обмен информацией 7.2 «Отставание графика, несоответствие функциональности, системные ошибки — все это из-за того, что левая рука не знает, что творит правая.» Предположения команд расходятся.

7.3 Бригады должны поддерживать между собой связь всеми возможными способами: неформально, путем регулярных совещаний по проекту с техническими отчетами и через общую рабочую тетрадь проекта. (А также электронную почту.) Рабочая тетрадь проекта 7.4 Рабочая тетрадь проекта есть «не столько отдельный документ, сколько структура, налагаемая на все документы, которые, так или иначе, будут созданы во время выполнения проекта.» 7.5 «Все документы проекта должны входить в эту структуру (рабочей тетради).» 7.6 Структуру рабочей тетради нужно проектировать тщательно и рано.

7.7 Правильное структурирование текущей документации с самого начала позволяет «составленные позднее документы оформить в виде отрывков, которые вписываются в эту структуру» и улучшает руководства по продукту.

7.8 «Каждый член команды должен видеть все материалы (рабочей тетради).» (Сейчас я бы сказал «должен иметь возможность видеть». Например, достаточно WWW-страниц.) 7.9 Своевременное обновление может иметь критическое значение.

7.10 Необходимо, чтобы внимание пользователя было особо привлечено к изменениям, произошедшим после его последнего прочтения, причем с пометками об их значении.

7.11 Рабочая тетрадь проекта OS/360 начиналась с бумажного варианта с последующим переходом на микрофиши.

7.12 Сегодня (и даже в 1975 году) общий электронный блокнот является значительно лучшим, более дешевым и простым механизмом достижения этих целей.

7.13 Необходимо помечать текст с помощью полосок изменения дат пересмотра (или их функционального эквивалента). Так же необходима сводка изменений по типу стека.

7.14 Парнас старается доказать, что стремление к тому, чтобы каждый видел все, совершенно ошибочно: части должны инкапсулироваться таким образом, чтобы никому не требовалось или не разрешалось видеть содержание каких либо частей, кроме своих собственных, а видны могут быть только интерфейсы.

7.15 Предложение Парнаса — путь к катастрофе. (Парнас вполне убедил меня в обратном, и я совершенно изменил свое мнение.) Организация 7.16 Задачей организации является сокращение объема необходимого общения и согласования.

7.17 Организация заключает в себе разделение труда и специализацию функций с целью сократить обмен информацией.

7.18 Обычная древовидная организация отражает структурный принцип власти, который показывает, что нельзя одновременно служить двум хозяевам.

7.19 Структура обмена информацией в организации является не деревом, а сетью, и нужно придумать различные виды специальных организационных механизмов («пунктирные линии»), чтобы преодолеть дефицит обмена информацией в древовидной организации.

7.20 В каждом субпроекте есть две руководящие должности: продюсер и технический директор, или архитектор. Их функции совершенно различны и требуют разных способностей.

7.21 Вполне эффективным может быть любой тип взаимоотношений между этими двумя должностями:

• Это может быть одно лицо.

• Продюсер может быть начальником, а директор — его правой рукой.

• Директор может быть начальником, а продюсер — его правой рукой.

Глава 8. Объявляя удар 8.1 Нельзя точно оценить общий объем или график работ программного проекта, просто оценив время написания программы и умножив на некоторые коэффициенты для остальных частей задания.

8.2 Данные, относящиеся к созданию небольших отдельных систем, не применимы к проектам создания программных комплексов.

8.3 Объем работ растет как степенная функция размера программы.

8.4 Некоторые опубликованные исследования показывают, что показатель степени примерно равен 1,5. (Результаты Бёма с этим не согласуются и меняются от 1,05 до 1,2.) 8.5 Данные Портмана по ICL показывают, что занятые на полный рабочий день программисты только около 50 процентов времени занимаются программированием и отладкой, а остальное время занимают разные дополнительные задачи.

8.6 По данным Арона из IBM, производительность труда лежит в пределах от 1, до 10 тысяч строк программы на человека в год в зависимости от количества взаимодействий между частями системы.

8.7 По данным Харра из Bell Labs, производительность труда при задаче типа разработки операционной системы составила около 0,6 тысяч строк кода на человека в год, а при разработке компиляторов — 2,2 тысячи для законченных продуктов.

8.8 Данные Брукса по OS/360 согласуются с данными Харра: 0,6-0,8 тысяч строк кода на человеко-год для операционных систем и 2-3 тысячи для компиляторов.

8.9 Данные Корбато по проекту МТИ MULTICS показывают, что производительность труда при разработке смеси операционной системы и компиляторов составила 1,2 тысяч строк кода на человека в год, но это строки кода PL/I, а остальные данные относятся к строкам кода ассемблера!

8.10 Производительность примерно постоянна в переводе на элементарные операторы.

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

Глава 9. Два в одном 9.1 Если не считать времени выполнения, то главные издержки приходятся на занимаемое программой пространство памяти. Это в особенности верно для операционных систем, значительная часть которых остается резидентной.

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

9.3 Разработчик программы должен устанавливать задание по размеру, контролировать размер и придумывать методы сокращения размера, так же, как разработчик аппаратной части делает это для деталей.

9.4 Ресурсы по памяти должны явно задавать не только размер резидентной части, но и интенсивность обращений программы к диску.

9.5 Ресурсы памяти должны привязываться к назначению функций: точно определяйте, что должен делать модуль, когда задаете его размеры.

9.6 Группы в составе больших бригад склонны производить оптимизацию в своих узких интересах, не думая о конечном эффекте, который она окажет на пользователя. Эта потеря ориентации является большой опасностью для крупных проектов.

9.7 На всем протяжении реализации системные архитекторы должны постоянно проявлять бдительность с целью непрерывного обеспечения целостности системы.

9.8 Воспитание общесистемного и ориентированного на пользователя подхода является, возможно, главной задачей менеджера по программированию.

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

9.10 Важно определить размер транзитной памяти, связанный с размером перегружаемого кода, поскольку зависимость производительности от этого размера сильнее, чем линейная. (Этот пункт полностью устарел благодаря наличию виртуальной памяти и дешевизне физической памяти. Теперь пользователи обычно покупают память в количестве, достаточном для размещения всего кода основных приложений.) 9.11 Для достижения хорошего компромисса между пространством и временем необходимо проводить обучение технике программирования, присущей данному языку или машине, особенно если они новые.

9.12 У программирования есть технология, и каждый проект нуждается в библиотеке стандартных компонентов.

9.13 Библиотеки программ должны иметь по две версии каждого компонента — быструю и компактную. (Похоже, что сегодня это устарело.) 9.14 Компактные и быстрые программы почти всегда являются результатом стратегического прорыва, а не тактической грамотности.

9.15 Таким прорывом часто является новый алгоритм.

9.16 Еще чаще прорыв происходит благодаря изменению представления данных или таблиц. Представление — сущность программирования.

Глава 10. Документарная гипотеза 10.1 Гипотеза: Среди моря бумаг несколько документов становятся критически важными осями, вокруг которых вращается все управление проектом. Они являются главными личными инструментами менеджера.

10.2 Для проекта разработки компьютера решающими документами являются цели, руководство, график, бюджет, организационная структура, план помещений, а также оценка, прогноз и цены для самой машины.

10.3 Для факультета университета важнейшие документы аналогичны: цели, требования к соискателям степеней, описания курсов, предложения по научной работе, расписание занятий и план обучения, бюджет, план помещений, а также назначения преподавателей и аспирантов.

10.4 Для программного проекта требования те же: цели, руководство пользователя, внутренняя документация, график, бюджет, организационная структура и план помещений.

10.5 Поэтому даже для самого маленького проекта менеджер с самого начала должен формализовать такой набор документов.

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

10.7 Сопровождение каждого важного документа требует наличия механизма слежения за состоянием и предупреждения.

10.8 Каждый документ в отдельности служит контрольным списком и базой данных.

10.9 Важнейшая задача менеджера — обеспечить общее движение в одном направлении.

10.10 Главная постоянная задача менеджера — общение, а не принятие решений;

документы информируют всю команду о планах и решениях.

10.11 Только маленькая часть, возможно, 20 процентов, рабочего времени администратора занята задачами, которые требуют сведений, отсутствующих в его памяти.

10.12 По этой причине модная идея «всеохватывающей информационной системы для управления», обеспечивающей поддержку руководителя, основывается на неверной модели поведения руководителя.

Глава 11. Планируйте на выброс 11.1 Инженеры-химики выяснили, что осуществленный в лаборатории процесс нельзя одним махом перенести в заводские условия, но необходимо построить опытный завод, чтобы получить опыт наращивания количеств веществ и функционирования в незащищенных средах.

11.2 Этот промежуточный шаг в равной мере необходим для программных продуктов, но для инженеров-программистов пока не стало обычной практикой проводить полевые испытания опытной системы, прежде чем начинать поставки готового продукта. (Сейчас это уже стало общей практикой благодаря выпуску бета-версий. Это не то же самое, что макет с ограниченной функциональностью, альфа-версия, которую я также пропагандирую.) 11.3 Для большинства проектов первую построенную версию едва можно использовать: слишком медленная, слишком большая, слишком сложная в применении, или все это вместе.

11.4 Отбросить и перепроектировать можно все сразу, а можно по частям, но все равно это придется сделать.

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

11.6 Поэтому планируйте выбросить первую версию — вам все равно придется это сделать.

11.7 «Программист поставляет удовлетворение потребности пользователя, а не какой-то осязаемый продукт» (Косгроув).

11.8 Как фактические потребности пользователя, так и понимание им своих потребностей меняются во время создания, тестирования и использования программы.

11.9 Податливость и неосязаемость программного продукта побуждают его создателей (исключительно) к вечному изменению требований.

11.10 Некоторые законные изменения в задачах (и стратегиях разработки) неизбежны, и лучше подготовиться к ним заранее, чем предполагать, что их не будет.

11.11 Способы проектирования системы с учетом будущих изменений, особенно структурное программирование с тщательным документированием интерфейсов модулей, хорошо известны, но не всегда применяются. Полезно также, где только можно, использовать технологии табличного управления.

(Такая техника благодаря стоимости и размеру памяти в настоящее время применяется все более успешно.) 11.12 Для сокращения вносимых при изменениях ошибок следует использовать языки высокого уровня, операции времени компиляции, встраивание ссылок на объявления и технику самодокументирования.

11.13 Вносите изменения квантами в хорошо определенные нумерованные версии.

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

11.15 Создавать организационную структуру с учетом внесения в будущем изменений значительно труднее, чем проектировать систему с учетом будущих изменений.

11.16 Руководитель проекта должен стремиться к тому, чтобы его менеджеры и технический персонал были настолько взаимозаменяемы, насколько позволяют их способности. В частности, нужно иметь возможность легко переводить людей с технической на управленческую работу и обратно.

11.17 Препятствия к поддержанию эффективной организации с двойной служебной лестницей являются социологическими. Необходимо постоянно бдительно и энергично бороться с ними.

11.18 Легко установить соответствующие размеры жалованья для соответствующих ступенек двойной лестницы, но требуется принять меры, чтобы дать им соответствующий престиж: одинаковые офисы, одинаковые службы поддержки, в значительной мере компенсирующие управленческую деятельность.

11.19 Организация по типу операционной бригады позволяет активно решать все стороны этой проблемы. Это действительно долгосрочное решение проблемы гибкой организации.

Два шага вперед, шаг назад: сопровождение программ 11.20 Сопровождение программы в корне отличается от сопровождения аппаратной части;

оно состоит, главным образом, из изменений, исправляющих конструктивные дефекты, включение дополнительных функций или адаптацию к изменениям среды использования или конфигурации.

11.21 Стоимость пожизненного сопровождения широко используемой программы обычно составляет 40 и более процентов стоимости ее разработки.

11.22 Стоимость сопровождения сильно зависит от числа пользователей: чем больше пользователей, тем больше ошибок они находят.

11.23 Кэмпбел отмечает интересную кривую взлета и падений обнаруживаемых ошибок в течение жизни продукта.

11.24 Исправление одной ошибки с большой вероятностью (от 20 до 50 процентов) вносит другую.

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

11.26 Методы разработки программ, позволяющие исключить или по крайней мере выявить побочные эффекты, могут резко снизить стоимость сопровождения.

11.27 То же можно сказать о методах реализации проектов меньшим числом интерфейсов и меньшим количеством ошибок.

Шаг вперед, шаг назад: энтропия системы с течением времени растет 11.28 Леман и Белади считают, что общее количество модулей растет линейно с номером версии операционной системы (OS/360), но числи модулей, затронутых изменениями, растет экспоненциально в зависимости от номера версии.

11.29 Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Даже самое искусное сопровождение программы только отдаляет момент повержения ее в состояние неисправимого хаоса, выходом из которого является повторное проектирование с самого начала. (Иногда реальная необходимость обновления программы, например, с целью повышения производительности, вызывает необходимость изменения внутренних границ структур. Часто исходные границы служат причиной выявляющихся впоследствии недостатков.) Глава 12. Острый инструмент 12.1 Менеджер проекта должен установить принципы и выделить ресурсы для разработки общеупотребляемых инструментов, в то же время он должен признать необходимость в персонализированных инструментах.

12.2 Бригадам, разрабатывающим операционные системы, необходима для отладки собственная целевая машина. Для нее требуется скорее максимум памяти, чем максимум скорости, и системный программист для поддержки стандартного программного обеспечения.

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

12.4 Потребность в целевой машине описывается специфической кривой: после низкой активности следует взрывной рост, который потом выравнивается.

12.5 Системной отладкой, как астрономией, всегда занимались преимущественно по ночам.

12.6 Вопреки теории, выделение времени целевой машины одной бригаде значительными блоками оказалось лучшим вариантом планирования времени, чем чередование использования машины бригадами.

12.7 Этот предпочтительный при нехватке компьютеров метод планирования времени пережил 20 лет (с 1975 года) технологических изменений, поскольку является наиболее продуктивным. (И остается им в 1995 году.) 12.8 Если целевой компьютер является новым, необходим его логический эмулятор. Его можно получить раньше, и он обеспечивает надежную машину для отладки даже после того, как поставляется настоящая машина.

12.9 Главную библиотеку программ нужно разделить на: 1) набор индивидуальных «игровых площадок», 2) подбиблиотеку системной интеграции, проходящую системное тестирование и 3) версию-релиз. Формальное разделение и перемещение обеспечивают контроль.

12.10 Инструмент, обеспечивающий наибольшую экономию труда в программном проекте, — это, наверное, система редактирования текстов.

12.11 Объемистость системной документации создает новый тип непостижимости (см., например Unix), но это значительно предпочтительнее, чем более распространенный крайний недостаток документации.

12.12 Создайте эмулятор производительности снаружи внутрь, сверху вниз. Начните работу с ним как можно раньше. Прислушайтесь к тому, что он вам скажет.

Языки высокого уровня 12.13 Только лень и инертность препятствуют повсеместному применению языков высокого уровня и интерактивного программирования. (Но сегодня они приняты повсеместно.) 12.14 Язык высокого уровня способствует не только увеличению производительности, но и отладке. Меньше ошибок и легче поиск.

12.15 Прежние возражения, связанные с функциональностью, размером и скоростью результирующей программы устарели благодаря развитию языков и технологии компиляции.

12.16 Сегодня единственный подходящий кандидат для системного программирования — PL/I. (Больше не соответствует действительности.) Интерактивное программирование 12.17 В некоторых приложениях пакетные системы никогда не будут вытеснены интерактивными системами. (По-прежнему верно.) 12.18 Отладка — это тяжелая и долгая часть системного программирования, и медленная оборачиваемость является проклятием отладки.

12.19 Есть свидетельства тому, что интерактивное программирование по крайней мере удваивает скорость системного программирования.

Глава 13. Целое и части 13.1 Детальная и старательная проработка архитектуры согласно главам 4, 5 и не только упрощает использование продукта, но также облегчает его разработку и делает менее подверженным ошибкам.

13.2 Высоцкий говорит, что «очень многие неудачи связаны именно с теми аспектами, которые были не вполне специфицированы».

13.3 Задолго до всякого написания программы спецификация должна быть передана сторонней группе тестирования для тщательного рассмотрения полноты и ясности. Сами разработчики сделать это не могут.

13.4 «Нисходящее проектирование Вирта (с пошаговым уточнением) является самой важной новой формализацией программирования за десятилетие (1965 1975).» 13.5 Вирт проповедует использование на каждом шаге нотации возможно более высокого порядка.

13.6 Хорошее нисходящее проектирование помогает избегать ошибок благодаря четырем обстоятельствам.

13.7 Иногда приходится возвращаться назад, отбрасывать самый верхний уровень и начинать все сначала.

13.8 Структурное программирование, т.е. разработка программ, управляющие структуры которых состоят только из заданного набора операторов, воздействующих на блоки кода (в противоположность беспорядочным переходам), дает верный способ избежать ошибок и представляет собой правильный способ мышления.

13.9 Экспериментальные данные Голда показывают, что во время первого диалога каждого сеанса достигается втрое больший прогресс в интерактивной отладке, чем при последующих диалогах. Все же полезно тщательно спланировать отладку, прежде чем регистрироваться на машине. (Я полагаю, что это полезно до сих пор, в 1995 году.) 13.10 Я считаю, что для правильного использования хорошей системы (интерактивной отладки с быстрой реакцией) на каждые два часа работы за столом должно приходиться два часа работы на машине: один час — на подчистки и документирование после первого сеанса, и один час — на планирование изменений и тестов очередного сеанса.

13.11 Системная отладка (в отличие от отладки компонентов) занимает больше времени, чем ожидается.

13.12 Трудность системной отладки оправдывает тщательную систематичность и плановость.

13.13 Системную отладку нужно начинать, только убедившись в работоспособности компонентов, (в противоположность подходу «свинти и попробуй» и началу системной отладки при известных, но не устраненных ошибках в компонентах). (Это особенно справедливо для бригад.) 13.14 Рекомендуется создать большое окружение и много проверочного кода и «лесов» для отладки, возможно, на 50 процентов больше, чем сам отлаживаемый продукт.

13.15 Необходимо контролировать изменения и версии, при этом члены команды пусть играют со своими копиями на «площадках для игр».

13.16 Во время системного тестирования добавляйте компоненты по одному.

13.17 Леман и Белади свидетельствуют, что квант изменений должен быть либо большим и вноситься редко, либо очень маленьким — и часто. Последний случай более чреват неустойчивостью. (В Microsoft работают маленькими частыми квантами. Разрабатываемая система собирается заново каждые сутки.) Глава 14. Назревание катастрофы 14.1 «Как оказывается, что проект запаздывает на один год? …Сначала он запаздывает на один день.» 14.2 Отставание, растущее понемногу изо дня в день, труднее распознать, труднее предотвратить, труднее выправить.

14.3 Чтобы управлять большим проектом по жесткому графику, надо прежде всего иметь график, состоящий из вех и соответствующих им дат.

14.4 Вехи должны быть конкретными, специфическими, измеримыми событиями, определенными с предельной точностью.

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

14.6 Исследования поведения правительственных подрядчиков по проведению оценок в крупных проектах показали, что оценки сроков работы, тщательно пересматриваемые каждые две недели, незначительно меняются по мере приближения начала работ, что во время работ переоценки уверенно снижаются и что недооценки не меняются, пока до запланированного срока окончания работ не остается около трех недель.

14.7 Хроническое отставание от графика убивает моральный дух. (Джим Маккарти из Microsoft говорит: «Если вы пропустили один крайний срок, будьте уверены, что пропустите и второй.»2) 14.8 Для выдающихся команд программистов характерна энергия, как и для выдающихся бейсбольных команд.

14.9 Ничто не заменит график с критическими путями, чтобы определить, какое отставание во что обойдется.

14.10 Подготовка диаграммы критических путей есть самая ценная часть ее применения, поскольку определение топологии сети, указание зависимостей в ней и оценивание путей вынуждают осуществить большой объем очень конкретного планирования на самых ранних стадиях проекта.

14.11 Первая диаграмма всегда ужасна, и для создания второй приходится проявить много изобретательности.

14.12 Диаграмма критических путей дает отпор деморализующей оговорке «другая часть тоже запаздывает».

14.13 Каждому начальнику нужны два вида данных: информация о срывах плана, которая требует вмешательства, и картина состояния дел, чтобы быть осведомленным и иметь раннее предупреждение.

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

14.15 Неправильными действиями начальник может обеспечить утаивание всей картины состояния дел;

напротив, тщательное рассмотрение отчетов без паники и вмешательства поощряет честный доклад.

14.16 Необходимо иметь методологию обзора, с помощью которой подлинное положение вещей становится известным всем игрокам. Главным для этой цели является график с вехами и документ о завершении.

14.17 Высоцкий: «Я нашел, что удобно иметь в отчете о состоянии работ две даты — «плановую» (дату начальника) и «оцениваемую» (дату менеджера низшего звена). Менеджер проекта должен осторожно относиться к оцениваемым датам.» 14.18 Небольшая группа планирования и контроля, дающая отчеты о прохождении вех, неоценима при работе над большим проектом.

Глава 15. Обратная сторона 15.1 Для программного продукта сторона, обращенная к пользователю, — документация — столь же важна, как и сторона, обращенная к машине.

15.2 Даже для программ, написанных исключительно для себя, текстуальная документация необходима: память может изменить автору-пользователю.

15.3 В целом, преподавателям и менеджерам не удалось воспитать на всю жизнь у программистов уважение к документации, преодолевающее лень и пресс графика работ.

15.4 Эта неудача вызвана не столько недостатком старания или красноречия, сколько неспособностью показать, как проводить документирование эффективно и экономично.

15.5 Документация часто страдает отсутствием общего обзора. Посмотрите сначала издалека, а потом медленно приближайтесь.

15.6 Важная документация пользователя должна быть вчерне написана до разработки программы, поскольку в ней содержатся основные плановые решения. В ней должны быть описаны девять предметов (см. текст главы).

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

15.8 Внутренняя документация программы, предназначенная тому, кто должен ее модифицировать, также должна содержать текстуальный обзор, в котором должны быть описаны пять предметов (см. главу).

15.9 Блок-схема чаще всего напрасно включается в документацию. Подробная пошаговая блок-схема устарела благодаря письменным языкам высокого уровня. (Блок-схема — графический язык высокого уровня.) 15.10 Редко требуется блок-схема более чем на одну страницу — если она вообще нужна. (Стандарт MILSPEC здесь совершенно не прав.) 15.11 Что действительно необходимо — это структурный граф программы без соблюдения стандартов составления блок-схем ANSI.

15.12 Чтобы обеспечить обновление документации, важно включить ее в исходный текст программы, а не держать отдельным документом.

15.13 Для облегчения труда ведения документации есть три важных правила:

• Как можно больше используйте для документирования обязательные части программы, такие как имена и объявления.

• Используйте свободное пространство и формат, чтобы показать отношения подчиненности, вложенности и улучшить читаемость.

• Вставляйте в программу необходимую текстовую документацию в виде параграфов комментариев, особенно в заголовках модулей.

15.14 В документации, которой будут пользоваться при модификации программы, объясняйте не только «как», но и «почему». Назначение является решающим для понимания. Даже языки высокого уровня совсем не передают значения.

15.15 Методы самодокументирующегося программирования наиболее полезны и мощны при использовании языков высокого уровня.

Эпилог к первому изданию E.1 Программные системы являются, возможно, самыми сложными и запутанными (в смысле числа различных типов составляющих) созданиями человека.

E.2 Смоляная яма программной инженерии еще долгое время будет оставаться вязкой.

Глава 19 «Мифический человеко-месяц» двадцать лет Глава 19 «Мифический человеко-месяц» двадцать лет Глава 19 «Мифический человеко-месяц» двадцать лет спустя спустя спустя Я не знаю другого способа судить о будущем, как с помощью прошлого.

ПАТРИK ГЕНРИ Опираясь на прошлое, невозможно планировать будущее.

ЭДМУНД БЕРK Для чего понадобилось юбилейное двадцатое издание?

Самолет гудел в ночи, направляясь к Лагардии. Облака и сумрак скрыли все интересное для глаза. Документ, который я читал, был неинтересным. Однако мне не было скучно. Сидящий рядом попутчик читал «Мифический человеко-месяц», и я ожидал, когда словом или жестом он выдаст свое впечатление. В конце концов, когда мы уже выруливали к выходу, я не выдержал:

— Как вам эта книга? Советуете прочесть?

— Хм, в ней нет ничего, чего я не знал бы раньше.

Я решил не представляться.

Почему «Мифический человеко-месяц» выжил? Почему с ним до сих пор считаются в современной практике программирования? Почему его читательская аудитория выходит за пределы сообщества программистов-разработчиков, а книга порождает статьи, цитаты и письма не только разработчиков программ, но и юристов, врачей, психологов, социологов? Каким образом книга, написанная 20 лет назад об опыте разработки программ, имевшем место 30 лет назад, может до сих пор быть актуальной и даже полезной?

Согласно одному из объяснений, которые можно услышать, разработка программного обеспечения как дисциплина не получила нормального и правильного развития. В поддержку этой точки зрения часто указывают на несоответствие роста производительности труда программистов и эффективности производства компьютеров, выросшей в тысячи раз за последние два десятилетия. Как объясняется в главе 16, аномалия состоит не в замедленном развитии программирования, а в беспрецедентном в истории человечества взрыве компьютерных технологий. В целом, причина этого в постепенном переходе производства компьютеров из сборочного производства в обрабатывающее, из трудоемкого производства в капиталоемкое. Разработка же аппаратного и программного обеспечения, в отличие от производства, остается по своей сути трудоемкой.

Второе часто выдвигаемое объяснение гласит, что «Мифический человеко-месяц» лишь случайно касается разработки программного обеспечения, а в основном он написан о групповой разработке чего бы то ни было. Доля правды в этом есть. В предисловии к изданию 1975 года сказано, что управление программным проектом имеет больше сходства с любым другим управлением, чем изначально считается большинством программистов. Я до сих пор так считаю. История человечества — это пьеса, в которой сюжеты постоянны, сценарии медленно меняются с развитием культуры, а декорации меняются непрерывно. Поэтому в ХХ веке мы узнаем себя в Шекспире, Гомере и Библии. Поэтому в той мере, в какой «МЧ-М» написан о людях, он устаревает медленно.

Каковы бы ни были причины, книгу продолжают покупать и присылают мне замечания, которые я ценю. Меня часто спрашивают: «Как вы считаете, в чем вы тогда ошиблись? Что устарело в наши дни? Что действительно новое появилось в мире разработки программ?» Эти четкие вопросы вполне законны, и я постараюсь ответить на них. Не в таком, правда, порядке, но по группам тем. Прежде всего, посмотрим, что было верным в момент написания и осталось таковым до сих пор.

Центральный аргумент: концептуальная целостность и архитектор Концептуальная целостность. Чистый и элегантный программный продукт должен представить своим пользователям согласованную идеальную модель приложения, стратегий осуществления приложения и тактики пользовательских интерфейсов, используемой при задании действий и параметров. Концептуальная целостность продукта в восприятии пользователя является важнейшим фактором, влияющим на простоту использования. (Есть, конечно, и другие факторы. Важным примером является единообразие пользовательского интерфейса в приложениях для Macintosh.

Более того, можно создать согласованные интерфейсы, являющиеся тем не менее, совершенно неуклюжими. Например MS-DOS.) Есть многочисленные примеры элегантных программных продуктов, созданных одним или двумя людьми. Так делается большая часть чисто интеллектуальных продуктов, таких как книги или музыкальные произведения. Однако во многих промышленных областях процессы разработки продукта не могут осуществляться на основе столь простого подхода к концептуальной целостности. Конкуренция вынуждает к спешке. Во многих современных технологиях конечный продукт обладает большой сложностью, и проектирование неизбежно требует многих человеко-месяцев труда. Для программных продуктов характерны как сложность, так и напряженность графика, обусловленная конкуренцией.

Таким образом, всякий достаточно большой или срочный продукт, требующий усилий многих людей, сталкивается со специфической трудностью: результат должен концептуально согласовываться с разумом одиночного пользователя и в то же время проектироваться усилиями нескольких разумов. Как организовать проектирование, чтобы достичь такой концептуальной целостности? Это центральный вопрос «МЧ-М». Один из его тезисов гласит, что существуют качественные различия между управлением большими и маленькими программными проектами — лишь в силу числа работающих над ними голов. Для достижения согласованности необходимы обдуманные и даже героические действия.

Архитектор. С четвертой по шестую главу я доказываю, что самое важное — назначить одного человека архитектором продукта, ответственным за все его стороны, воспринимаемые пользователем. Архитектор формирует и имеет в своем владении общедоступную идеальную модель продукта, с помощью которой пользователю будет объяснено его применение. В ее состав входит подробное указание всех его функций и средств вызова и управления. Архитектор также действует в интересах пользователя при поиске компромисса между функциями, техническим характеристиками, размером, стоимостью и выполнением графика работ. Выполнение этой задачи требует полной занятости, и только в очень маленьких группах может быть совмещено с должностью руководителя. Архитектора можно сравнивать с режиссером, а менеджера — с продюсером кинокартины.

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

Рекурсивность архитектуры. В очень больших проектах одному человеку не справиться со всей архитектурой, даже если он избавлен от всех забот, связанных с разработкой. Поэтому главный архитектор системы должен разбить целое на подсистемы. Границы подсистем должны быть проведены так, чтобы интерфейсы между ними были минимальны и легче всего строго определяемы. Тогда у каждой части может быть свой архитектор, подчиняющийся главному архитектору системы в отношении архитектуры. Очевидно, при необходимости этот процесс может быть продолжен рекурсивно.

Сегодня я убежден более чем когда-либо. Концептуальная целостность является важнейшим условием качества продукта. Наличие системного архитектора есть важнейший шаг в направлении концептуальной целостности. Эти принципы ни в коей мере не ограничиваются разработкой программного обеспечения, а справедливы при проектировании любой сложной конструкции, будь то компьютер, самолет, стратегическая оборонная инициатива или система глобальной навигации.

После преподавания в более чем 20 лабораториях разработки программного обеспечения я стал настаивать, чтобы группы учащихся, даже из четырех человек, выбирали менеджера и отдельно — архитектора. Разделение функций в таких маленьких группах может показаться несколько чрезмерным требованием, но, по моим наблюдениям, это оправдано и способствует достижению успеха.

Эффект второй системы: функциональность и угадывание частоты Проектирование для больших групп пользователей. Одним из последствий революции, произведенной персональными компьютерами, является все возрастающее, по крайней мере в области обработки деловых данных, вытеснение заказных программ коробочными программными пакетами. Более того, стандартные программные пакеты продаются сотнями тысяч и даже миллионами экземпляров.

Системные архитекторы программ, поставляемых вместе с машиной, всегда должны были создавать проект, ориентированный на большую аморфную массу пользователей, а не на отдельное определенное приложение в одной компании.

Теперь такая задача встает перед очень многими архитекторами.

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

В погоне за функциональностью. Архитектор инструмента общего назначения, такого, например, как электронная таблица или текстовый редактор, подвержен сильному соблазну перегрузить продукт функциями предельной полезности ценой снижения производительности и даже простоты использования. Вначале привлекательность предлагаемых возможностей кажется очевидной. Расплата производительностью становится очевидной лишь при системном тестировании.

Утрата простоты использования коварно подкрадывается по мере того, как небольшими порциями добавляются новые функции, а руководства пользователя все более разбухают. Соблазн особенно велик в отношении долгоживущих массовых продуктов, развивавшихся на протяжении ряда поколений. Миллионы покупателей требуют сотен новых возможностей. Всякая просьба свидетельствует о наличии спроса на рынке. Часто архитектор первоначальной системы уже ушел в поход за новой славой, и архитектура оказалась в руках людей с меньшим опытом взвешенного представления общих интересов пользователей. В недавней рецензии на Microsoft Word 6.0 сказано: «Переполнен возможностями;

обновление замедлено перегруженностью… Кроме того, Word 6.0 занимает много места и медленно работает.» С неудовольствием отмечается, что Word 6.0 занимает 4 Мбайт памяти и сообщается, что из-за богатых дополнительных функциональных возможностей «даже Macintosh IIfx едва пригоден для выполнения Word 6». Определение группы пользователей. Чем крупнее и аморфнее группа предполагаемых пользователей, тем более необходимо явно ее определить, если вы намерены достичь концептуальной целостности. У каждого члена группы проектировщиков наверняка есть неявный мысленный образ пользователя, и все образы будут отличаться друг от друга. Поскольку представление архитектора о пользователе явно или подсознательно оказывает влияние на все архитектурные решения, важно, чтобы команда проектировщиков пришла к единому общему образу. Для этого необходимо составить список признаков предполагаемых пользователей, указав в нем:

• кто они такие, • что им нужно, • что, по их мнению, им нужно, • чего они хотят.

Частоты. Для любого программного продукта каждая характеристика пользователя представляет собой распределение со множеством возможных значений и соответствующими частотами. Как архитектору получить эти частоты? Изучение этой слабо очерченной популяции представляется сомнительным и дорогостоящим занятием.3 С годами я пришел к убеждению, что архитектор должен угадать или, если вам больше нравится, постулировать полный набор признаков и значений вместе с частотами для создания полного, явного и общего для всех описания группы пользователей.

Такая непривлекательная процедура имеет ряд полезных последствий. Во-первых, при стремлении точно угадать частоты архитектор вынужден очень тщательно обдумать, какова возможная группа пользователей. Во-вторых, при фиксации частот возникает обсуждение, полезное для всех участников и выявляющее различия в образах пользователя, имеющихся у разных проектировщиков. В-третьих, явное присвоение частот содействуют пониманию того, какие решения какими свойствами группы пользователей обусловлены. Даже такой неформальный анализ чувствительности приносит пользу. Когда обнаруживается, что очень важные решения зависят от некоторых специфических предположений, оказывается уместным получить более точные численные оценки. (Разработанная Джеффом Конклином (Jeff Conklin) система позволяет формально и точно прослеживать принятие проектных решений и документировать их основания.4 Мне не приходилось ею пользоваться, но думаю, что она должна быть очень полезна.) Подводя итоги: установите предположительные признаки группы пользователей.

Гораздо лучше ошибаться, но выражаться ясно, чем выражаться туманно.

Как насчет эффекта второй системы? Один наблюдательный ученый заметил, что «Мифический человеко-месяц» рекомендовал на случай неудачи для всякой новой системы планировать поставку второй версии (см. глава 11), которая в главе характеризуется как таящая наибольшие опасности. Я вынужден был признать, что он меня «поймал».

Pages:     | 1 | 2 || 4 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.