Мифический человеко-месяц или как создаются программные системы
Добавить в закладки К обложке
- Посвящение издания 1975 года - Страница 1
- Предисловие к изданию 1995 года - Страница 2
- Предисловие к первому изданию - Страница 4
- Глава 1 Смоляная яма - Страница 6
- Глава 2 Этот мифический «человеко-месяц» - Страница 9
- Глава 3 Операционная бригада - Страница 13
- Глава 4 Аристократия, демократия и системное проектирование - Страница 17
- Глава 5 Эффект второй системы - Страница 21
- Глава 6 Донести слово - Страница 24
- Глава 7 Почему не удалось построить Вавилонскую башню? - Страница 28
- Глава 8 Объявляя удар - Страница 33
- Глава 9 Два в одном - Страница 36
- Глава 10 Документарная гипотеза - Страница 39
- Глава 11 Планируйте на выброс - Страница 41
- Глава 12 Острый инструмент - Страница 45
- Глава 13 Целое и части - Страница 50
- Глава 14 Назревание катастрофы - Страница 55
- Глава 15 Обратная сторона - Страница 58
- Глава 16 Серебряной пули нет — сущность и акциденция в программной инженерии - Страница 62
- Глава 17 Новый выстрел «Серебряной пули нет» - Страница 73
- Глава 18 Заявления «Мифического человеко-месяца»: правда или ложь? - Страница 82
- Глава 19 «Мифический человеко-месяц» двадцать лет - Страница 91
- Эпилог Пятьдесят лет удивления, восхищения и радости - Страница 106
- Примечания и ссылки - Страница 107
Глава 4 Аристократия, демократия и системное проектирование
Этот величественный храм является выдающимся произведением искусства. В принципах, которые он излагает, нет ни сухости, ни беспорядка…
Это вершина стиля, труд художников, которые поняли и восприняли все достижения своих предшественников, в совершенстве владея техникой своего века, но пользовались ей, избегая нескромного показа или необоснованной демонстрации мастерства.
Несомненно, замысел общего плана здания принадлежит д’Орбе, и те, кто его сменил, придерживались этого плана, по крайней мере, в существенных чертах. Это одна из причин удивительной гармоничности и единства здания.
ПУТЕВОДИТЕЛЬ ПО РЕЙМСКОМУ СОБОРУ[1]
Концептуальное единство
У большинства европейских соборов части, построенные разными поколениями строителей, имеют различия в планировке и архитектурном стиле. Более поздние строители испытывали соблазн «улучшить» проект своих предшественников, чтобы отразить новые веяния моды и свои личные вкусы. В итоге мирный норманнский трансепт создает конфликт с примыкающим к нему возносящимся в высь готическим нефом, и результат столь же служит восхвалению славы Господней, сколь и гордыни строителей.
Архитектурное единство Реймского собора находится в прямой противоположности с таким смешением стилей. Источником наполняющей зрителя радости служат как цельность конструкции, так и отдельные образцы совершенства. Как сказано в путеводителе, цельность была достигнута благодаря самоотречению восьми поколений строителей собора, пожертвовавших своими идеями ради чистоты общего замысла. То что получилось в результате, служит восхвалению не только славы Господней, но и Его могущества, способного спасти грешных людей от их гордыни.
Хотя на создание программных систем не уходят века, в большинстве своем они демонстрируют меньшую согласованность концепций, чем в любом соборе. Обычно это происходит не оттого, что главные проектировщики сменяют друг друга, а потому, что проект расщепляется на ряд задач, выполняемых разными разработчиками.
Я убежден, что концептуальная целостность является важнейшей характеристикой системного проекта. Лучше убрать из системы отдельные необычные возможности и усовершенствования и реализовать единый набор конструктивных идей, чем оснастить ее многими хорошими, но невзаимосвязанными и несогласованными идеями. В этой и двух последующих главах мы изучим следствия этой концепции для проектирования программных систем:
• Как достичь концептуальной целостности?
• Не будет ли это требование причиной раскола на элиту, аристократический класс архитекторов — с одной стороны, и толпы плебеев-исполнителей, чьи творческие таланты и идеи подавляются, — с другой?
• Как удержать архитекторов от витания в облаках и разработки несущественных или чрезмерно дорогих спецификаций?
• Как добиться того, чтобы любая мелочь из созданной архитектором спецификации дошла до исполнителя, была им правильно понята и точно внедрена в продукт?
Достижение концептуальной целостности
Назначение системы программирования — облегчить использование компьютера. Для этого поставляются языки и различные средства, являющиеся, по сути, программами, вызываемыми и управляемыми возможностями языка. Но эти средства стоят денег: объем внешнего описания системы программирования в десять-двадцать раз больше описания собственно вычислительной системы. Пользователю оказывается значительно проще задать любую выбранную функцию, но выбор очень велик, и нужно помнить значительно больше вариантов и форматов.
Использование облегчается, только если выигрыш времени при задании функции превышает время, потраченное на обучение, запоминание и поиск руководств. Современные системы программирования дают такой выигрыш, но похоже, что в последние годы отношение выигрыша к затратам уменьшилось в результате добавления все более и более сложных функций. Я часто вспоминаю, как легко было использовать IBM 650, даже без ассемблера или вообще каких-либо программ.
Поскольку целью проектирования является простота использования, окончательную оценку проекта системы дает достигнутое отношение функциональности к сложности концепций. Ни функциональность, ни простота в отдельности не являются признаками хорошего проекта.
Это обстоятельство часто неправильно понимается. Operating System/360 превозносится своими создателями, как лучшая из когда-либо созданных, поскольку неоспоримо, что в ней больше функций. Функции, а не простота всегда служили критерием превосходства ее создателей. С другой стороны, создатели системы с разделением времени для PDP-10 превозносят ее превосходство ввиду простоты и немногочисленности положенных в основу идей. Однако по всем меркам ее функциональность ниже по классу, чем OS/360. Если в качестве критерия определена простота использования, становится очевидной несбалансированность этих систем, достигающих цели лишь наполовину.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112