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

• Название: Мифический человеко-месяц или как создаются программные системы
• Автор: Фредерик Брукс
• Жанр: Деловая литература

Эта книга - юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975 году. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта.

---

Как это работает

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

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

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

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

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

Масштабирование

До сих пор все было хорошо. Проблема, однако, состоит в том, как создавать продукты, на которые сейчас уходит не 20 или 30, а 5000 человеко-лет. Бригада из 10 человек может быть эффективна вне зависимости от своей организации, если задача целиком находится в ее компетенции. Но как использовать идею операционной бригады в задачах, для выполнения которых привлекаются сотни людей?

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

Рис. 3.1 Схема контактов между сотрудниками в бригаде из 10 человек

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

Глава 4 Аристократия, демократия и системное проектирование

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

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

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

ПУТЕВОДИТЕЛЬ ПО РЕЙМСКОМУ СОБОРУ[1]

Концептуальное единство

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

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

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

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

• Как достичь концептуальной целостности?

• Не будет ли это требование причиной раскола на элиту, аристократический класс архитекторов — с одной стороны, и толпы плебеев-исполнителей, чьи творческие таланты и идеи подавляются, — с другой?

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

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

Достижение концептуальной целостности

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

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

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

Это обстоятельство часто неправильно понимается. Operating System/360 превозносится своими создателями, как лучшая из когда-либо созданных, поскольку неоспоримо, что в ней больше функций. Функции, а не простота всегда служили критерием превосходства ее создателей. С другой стороны, создатели системы с разделением времени для PDP-10 превозносят ее превосходство ввиду простоты и немногочисленности положенных в основу идей. Однако по всем меркам ее функциональность ниже по классу, чем OS/360. Если в качестве критерия определена простота использования, становится очевидной несбалансированность этих систем, достигающих цели лишь наполовину.

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