Мифический человеко- месяц — Википедия«Мифический человеко- месяц или Как создаются программные системы» — книга Фредерика Брукса об управлении проектами в области разработки программного обеспечения, центральной темой которой стало то, что привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта. Эта идея стала известна под названием «закон Брукса». Наблюдения Брукса основаны на его опыте работы в IBM, полученном в ходе управления проектом по созданию операционной системы OS/3.


Для ускорения разработки им была предпринята неудачная попытка привлечения большего числа работников к проекту, сроки по которому уже были сорваны. Заметив свойство менеджеров повторять такие ошибки, Брукс насмешливо называл свою книгу «библией для программной инженерии»: «все её читали, но никто ей не следует!»Также Брукс утверждал, что написание компилятора языка. Алгол потребует шести месяцев — независимо от количества людей, вовлечённых в проект. Книга впервые была опубликована в 1.
Мифический человеко-месяц или как создаются программные системы. 2-е издание, юбилейное. 03.01.2012 в 01:36 1.49 Мб pdf 32 раза . Мифический человеко-месяц или как создаются программные системы. Брукс-младший, Фредерик.
Повторно книга вышла в виде юбилейного издания в 1. Серебряной пули нет», опубликованном в 1. В России второе издание было опубликовано издательством Символ- Плюс в 2. ISBN 5- 9. 32. 86- 0.
Название: Мифический человеко-месяц или как создаются программные системы. Автор: Брукс Фредерик. Перевод: Маккавеев С. Оценка: 4.7 из 5, .
Программный продукт отличается от программы: максимально обобщённым диапазоном и видом входных данныхтщательным тестированием, что является неожиданно сложным этапомналичием подробной документации. Программный продукт требует в 3 раза больших затрат времени, чем программа (глава 1). Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере по 2 причинам. В программировании, в отличие от, например, сбора хлопка, работа не может быть произвольно разделена на несколько независимых частей. Части проекта зависят друг от друга, и некоторые задачи можно начинать выполнять только после того, как будут закончены другие. Программисты должны тратить часть времени на взаимодействие друг с другом. Если есть N программистов, то количество пар программистов равно N(N—1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично.
Поэтому начиная с какого- то N, рост числа программистов замедляет выполнение проекта. Если сроки сорваны, наём новых программистов замедляет выполнение проекта и по другой причине: новичкам требуется время на обучение. В книге сформулирован «закон Брукса»: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше». При очень большом числе программистов проект может быть вообще никогда не закончен: из- за общей неразберихи, попытки исправить существующие ошибки в программном обеспечении порождают новые ошибки, так что система не улучшается (глава 2).
Разумно, если в группе разработчиков есть один «хороший» программист, реализующий самые критические части системы, и несколько других, помогающих ему или реализующих менее критические части. Так делаются хирургические операции.
Кроме того, по мнению Брукса, лучшие программисты работают в 5- 1. Для обеспечения концептуальной целостности системы необходимо отделить архитектуру от реализации. Один главный архитектор (или небольшая группа), действуя в интересах пользователя, решают, что должно входить в систему, а что не должно.
Простота очень важна; может быть полезным реализовать только часть возможностей, на которые способна система, потому что если система слишком сложна, часть её возможностей будет оставаться неиспользованной. Главный архитектор должен сформулировать свои решения в виде руководства для пользователя (глава 4).
Программист, разрабатывающий свою вторую систему, склонен добавлять все те возможности, которые он не смог добавить в свою первую систему (из- за нехватки времени). Поэтому вторая система часто получается перегруженной возможностями (глава 5).
Каждый менеджер проекта должен составить небольшой набор формальных документов, описывающих цели проекта, как, кем и когда они будут реализованы, и сколько они будут стоить. Эти документы могут вскрыть несоответствия, которые иначе было бы трудно заметить.
Каждая группа разработчиков получает набор требований к своей части системы, включая точное описание её функциональности и предельные требования к процессорному времени, занимаемой памяти, месту на диске и т. Вместо того чтобы строить предположения по поводу реализуемой им функции, разработчик должен задавать архитектору уточняющие вопросы, поскольку предположения могут оказаться совершенно неверными. Пилотная система выявит ошибки в проектировании, после чего она должна быть полностью переделана (глава 1. Эту идею Брукс отвергает через 2.
По мере создания системы, требования пользователя к ней могут меняться под влиянием его опыта работы с незаконченной системой. Эти пожелания пользователя следует учитывать, но только до какого- то момента, иначе работа над системой никогда не будет закончена. После этого спецификации замораживаются, и все последующие требования изменений откладываются до начала работы над следующей версией (глава 1.
Вместо того, чтобы каждый программист писал собственные утилиты, в каждой группе разработчиков должен быть один программист, ответственный за написание утилит для своей группы (например, генератор кода, создающий код в соответствии с какими- то спецификациями). Должна быть также группа, создающая утилиты для всех работающих над данной системой (глава 1. Брукс приводит 2 способа снизить стоимость разработки программного обеспечения: Нанять программистов только после того, как построена архитектура системы. Иначе при длительности этой стадии, например, в несколько месяцев программистам будет нечего делать. Купить часть программного обеспечения у других разработчиков.
Фредерик П. Проектирование процесса проектирования: записки компьютерного эксперта = The Design of Design: Essays from a Computer Scientist.
Книга Мифический человеко- месяц, или Как создаются программные системы, Брукс, 5- 9. Эта книга - юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта. Филипс Ксениум W6500 Инструкция. Если вы никогда не слышали об этой книге, вы можете поискать ссылки на нее в Интернете (Frederick P. Вам все сразу станет понятно.
Вот, например, как отзываются об этой книге заказчики крупнейшего зарубежного web- магазина Amazon. Об авторе. Фредерик Брукс - профессор вычислительной техники в школе бизнеса Кенан университета штата Северная Каролина в Чэпел Хилл. Он известен, прежде всего, как .
Помимо этого, Брукс занимался разработкой в IBM архитектуры компьютеров Stretch и Harvest. В 1. 98. 5 году Фредерик Брукс, Боб Эванс и Эрик Блох были награждены Национальной медалью в области технологии за проектирование разработки операционной системы Operating System/3. Доктор Брукс был членом национального и военного комитетов по науке, основал в Чэпел Хилл факультет вычислительной техники и возглавлял его с 1.
В настоящее время он занимается преподаванием и исследованиями в области архитектуры компьютеров, молекулярной графики и виртуальных сред.