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

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

Вводимые термины в книге:

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

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

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

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

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

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

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

Два секретаря — Администратору и редактору нужны секретари. Секретарь администратора обрабатывает переписку, связанную с проектом, а также документы, не относящиеся к продукту.

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

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

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

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

Полезные цитаты из контекста:
Об удовольствии создания программ

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

про оценку времени выполнения задач

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

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

В-третьих, поскольку менеджеры программных проектов не уверены в своих оценках, им часто недостает вежливого упрямства, как у шеф-повара ресторана «Антуан».

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

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

1/3 - планирование,
1/6 - написание программ,
1/4 - тестирование компонентов и предварительное системное тестирование,
1/4 - системное тестирование при наличии всех компонентов.

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

Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать еще или съесть его сырым. Тот же выбор встает и перед заказчиком программного обеспечения. У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым - с другого.

Закон Брукса

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

Система 10

Концептуальная целостность

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

Оптимизация

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

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

Количество ошибок по времени внедрения

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

Концептуальные ошибки дороже, чем синтаксические . К.О.

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

Как растить выдающихся проектировщиков?

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

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

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

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

Краеугольный камень в основании профессии менеджера проектов.

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

Концепция, проверенная временем. Феноменальный рост производительности в процессе разработки программного обеспечения – это не более чем миф. Пугающая в общем-то честность. Тем не менее идут годы, а исследователи продолжают «ломать копья» на эту тему. Главную роль в процессе разработки программного обеспечения Брукс отводит хорошим проектировщикам. После прочтения руководители поневоле задумаются: так ли необходимо экономить на аналитиках? Впрочем, главная цель исследования Брукса не в этом. «Мифический человеко-месяц», если угодно, призван закрепить за разработкой приложений статус творчества. Задача амбициозная, но, кажется, у Брукса действительно получилось ее выполнить. Новейшая научно-техническая революция служит тому доказательством.

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

Меняются методологии, появляются новые языки программирования, растет производительность аппаратного обеспечения, но книга продолжает оставаться актуальной. В чем секрет? Все просто: Брукс нашел нужную точку зрения. Разработка программного обеспечения – это не столько про технологии и инструменты, сколько про людей. Феноменальный рост IT-технологий породил массу иллюзий, заставив менеджеров проектов забыть про самое главное – своих сотрудников. Брукс вернул их на грешную землю.

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

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

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

Эта книга - юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975 году. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта. Если вы никогда не слышали об этой книге, вы можете поискать ссылки на нее в Интернете (Frederick P. Brooks, The Mythical Man-Month). Вам все сразу станет понятно.

Содержание
Предисловие к изданию 1995 года
Предисловие к первому изданию
Глава 1. Смоляная яма
Глава 2. Этот мифический "человеко-месяц"
Глава 3. Операционная бригада
Глава 4. Аристократия, демократия и системное проектирование
Глава 5. Эффект второй системы
Глава 6. Донести слово
Глава 7. Почему не удалось построить Вавилонскую башню?
Глава 8. Объявляя удар
Глава 9. Два в одном
Глава 10. Документарная гипотеза
Глава 11. Планируйте на выброс
Глава 12. Острый инструмент
Глава 13. Целое и части
Глава 14. Назревание катастрофы
Глава 15. Обратная сторона
Глава 16. Серебряной пули нет - сущность и акциденция в программной инженерии
Глава 17. Новый выстрел "Серебряной пули нет"
Глава 18. Заявления "Мифического человеко-месяца": правда или ложь?
Глава 19. "Мифический человеко-месяц" двадцать лет спустя
Эпилог
Примечания и ссылки.

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

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

Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:
Скачать книгу Мифический человеко - месяц или как создаются программные системы - Брукс Ф. - fileskachat.com, быстрое и бесплатное скачивание.

Скачать pdf
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России.

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

Основные тезисы книги

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

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

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

Команда проекта

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

Данные Портмана по ICL показывают, что занятые на полный рабочий день программисты только около 50 процентов времени занимаются программированием и отладкой, а остальное время занимают разные дополнительные задачи.

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

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

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

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

Архитектура информационной системы

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

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

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

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

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

Сопровождение информационной системы

Программному продукту грозит устаревание ещё до его завершения. Если систему не развивать, она морально устаревает.

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

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

Исправление одной ошибки с большой вероятностью (от 20 до 50 процентов) вносит другую. (из-за того, что во время сопровождения теряется архитектура).

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

Посвящается двоим людям, благодаря которым мои годы в IBM были особенно насыщенными:

Томасу Дж. Уотсону Младшему, чье глубокое внимание к людям по-прежнему ощущается в его фирме, и Бобу О. Эвансу, чье смелое руководство превратило работу в приключение.

Посвящение издания 1995 года

Посвящается Нэнси, Божьему дару для меня.

Предисловие к изданию 1995 года

К моему удивлению и удовольствию, «Мифический человеко-месяц» остается популярным через 20 лет после выхода. Тираж превысил 250 000 экземпляров. Меня часто спрашивают, какие из оценок и рекомендаций, изложенных в 1975 году, я по-прежнему считаю верными, а какие претерпели изменения, и в чем именно. Несмотря на то, что в моих лекциях этот вопрос время от времени затрагивается, я давно жду возможности изложить его в печатном виде.

Питер Гордон (Peter Gordon), являющийся сейчас совладельцем издательства Addison-Wesley, терпеливо и с пользой сотрудничает со мной с 1980 года. Он предложил подготовить юбилейное издание. Мы решили не исправлять оригинал, а перепечатать его в неприкосновенности, за исключением обычных опечаток, и дополнить мыслями, возникшими в более позднее время.

В главе 16 перепечатывается статья «Серебряной пули нет: сущность и акциденция в программной инженерии», опубликованная IFIPS (Международная федерация обществ по обработке информации) в 1986 году и явившаяся результатом опыта, полученного мною во время руководства исследованием использования программного обеспечения в военных областях, проводившегося Военным комитетом по науке. Мои соавторы по этому исследованию, а также наш исполнительный секретарь Роберт Л. Патрик, оказали мне неоценимое содействие в моем возвращении к крупным практическим программным проектам. Статья была перепечатана в издании IEEE “Computer” в 1987 году, благодаря которому получила широкую известность.

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

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

Глава 19 собственно и представляет собой попытку пересмотреть изначальные утверждения. Следует предупредить читателя, что излагаемые новые взгляды далеко не в той мере подкреплены «боевым опытом», как это было в первой части книги. Дело в том, что в последнее время я работал в университетской среде, а не в промышленности, и над небольшими, а не крупномасштабными проектами. С 1986 года я занимаюсь только преподавательской деятельностью в области разработки программного обеспечения, но не исследованиями в ней. Моя исследовательская работа больше касается виртуальных сред и их применений.

Уилер (Earl Wheeler) и Эдвард Йордон (Edward Yordon). Фэй Уард (Fay Ward) прекрасно выполнила техническую работу, связанную с изданием новых глав.

Я благодарен моим коллегам из Группы по программному обеспечению для военных целей Военного комитета по науке Гордону Беллу (Gordon Bell), Брюсу Бьюкенену (Bruce Buchanan), Рику Хейз-Роту (Rick Hayes-Roth) и особенно Дэвиду Парнасу - за их плодотворные идеи, а Ребеке Бирли (Rebekah Bierly) - за подготовку к печати статьи, опубликованной в данной книге в качестве главы 16. Анализ проблем программирования в категориях «сущность» (essence) и «акциденция» (accident) возникло благодаря Нэнси Гринвуд Брукс, использовавшей такой анализ в статье об обучении игре на скрипке методом Сузуки.

Обычаи издательства Addison-Wesley не позволили мне в предисловии к изданию 1975 года выразить благодарность его сотрудникам за сыгранную ими важную роль. Следует особенно отметить вклад двух человек: Нормана Стентона (Norman Stenton), являвшегося ответственным редактором, и Герберта Боуза (Herbert Boes), бывшего художественным редактором. Боуз создал изящный стиль, особо отмеченный одним из рецензентов: «широкие поля и творческое использование шрифтов и компоновки материала». Что еще важнее, он дал важный совет поместить в начале каждой главы свою картинку. (В то время у меня были только картинки Смоляных ям и Реймского собора.) Чтобы найти все картинки, мне потребовался целый год, но я бесконечно благодарен за совет.

Soli Deo gloria - Богу единому слава!

F. P. B., Jr. Чапел Хилл, Северная Каролина Март 1995

Предисловие к первому изданию

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

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

Мое профессиональное становление в вычислительной технике первоначально было связано с программированием, однако в период 1956-1963 годов, когда разрабатывались автономные управляющие программы и языки высокого уровня, я занимался, в основном, архитектурой компьютеров. Когда в 1964 году я стал менеджером проекта разработки Operating System/360, то обнаружил, что мир программирования совершенно изменился благодаря успехам, достигнутым за несколько последних лет.

Руководство разработкой OS/360 было очень поучительным, хотя и полным расстройств. Команде разработчиков, в том числе сменившему меня Ф. М. Трапнеллу (F. M. Trapnell), можно многим гордиться. Система содержит много отличных решений в конструкции и функционировании, и ей удалось получить широкое распространение. Некоторые идеи, в первую очередь, организация ввода/вывода, независимая от устройств, и управление внешними библиотеками стали техническими новинками, ныне широко используемыми. Сейчас эта система вполне надежна, достаточно производительна и весьма гибка.

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