Мифический человеко-месяц
Материал из Википедии — свободной энциклопедии
| Мифический человеко-месяц | |
|---|---|
| The Mythical Man-Month | |
 |
|
| Автор: | Фредерик Брукс |
| Язык оригинала: | английский |
| Оригинал издан: | 1975 |
| Издательство: | Addison–Wesley |
| ISBN 0201835959 | |
«Мифический человеко-месяц или Как создаются программные системы» — книга Фредерика Брукса об управлении проектами в области разработки программного обеспечения, центральной темой которой стало то, что привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта. Эта идея стала известна под названием «закон Брукса». Книга была впервые опубликована в 1975 году, тогда же она вышла и на русском языке. Повторно книга вышла в виде юбилейного издания в 1995-ом, вместе с комментариями автора и новым эссе «Серебряной пули нет». В России второе издание было опубликовано издательством Символ-Плюс, ISBN 5-93286-005-7.
Наблюдения Брукса основаны на его опыте работы в IBM, полученным в ходе управления проектом по созданию операционной системы OS/360. Для ускорения разработки им была предпринята неудачная попытка привлечения большего числа работников к проекту, сроки по которому уже были сорваны. Заметив свойство менеджеров повторять такие ошибки, Брукс насмешливо называл свою книгу «библией для программной инженерии»: «все её читали, но никто ей не следует!»
Также Брукс утверждал, что написание компилятора с языка Алгол потребует шести месяцев — независимо от количества людей, вовлечённых в проект.
[править] Основные идеи
[править] Мифический человеко-месяц
Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере по 2 причинам.
- В программировании, в отличие от, например, сбора хлопка, работа не может быть произвольно разделена на несколько независимых частей. Части проекта зависят друг от друга, и некоторые задачи можно начинать выполнять только после того, как будут закончены другие.
- Программисты должны тратить часть времени на взаимодействие друг с другом.
Если есть N программистов, то количество пар программистов N(N-1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.
Если сроки сорваны, наём новых программистов замедляет выполнение проекта и по другой причине: новичкам требуется время на обучение. В книге сформулирован Закон Брукса:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
При очень большом числе программистов проект может быть вообще никогда не закончен: из-за общей неразберихи, попытки исправить существующие баги порождают новые, так что система не улучшается.
[править] Программа и программный продукт
Программный продукт отличается от программы:
- максимально обобщённым диапазоном и видом входных данных
- тщательным тестированием, что является неожиданно сложным этапом
- наличием подробной документации
Программный продукт требует в 3 раза больших затрат времени, чем программа.
[править] Эффект второй системы
Программист, разрабатывающий свою вторую систему, склонен добавлять все те возможности, которые он не смог добавить в свою первую систему (из-за нехватки времени). Поэтому вторая система часто получается перегруженной возможностями.
[править] Концептуальная целостность
Для обеспечения концептуальной целостности системы необходимо отделить архитектуру от реализации. Один главный архитектор (или небольшая группа), действуя в интересах пользователя, решают, что должно входить в систему, а что не должно. «Очень крутая» идея может быть отвергнута, если предлагаемая возможность не вписывается в общий дизайн системы. Простота очень важна; может быть полезным реализовать только часть возможностей, на которые способна система, потому что если система слишком сложна, часть её возможностей будут оставаться неиспользованными.
Главный архитектор должен сформулировать свои решения в виде руководства для пользователя.
[править] Формальные документы
Каждый менеджер проекта должен составить небольшой набор формальных документов, описывающих цели проекта, как они будут реализованы, даты их реализации, и сколько они будут стоить. Эти документы могут вскрыть несоответствия, которые иначе было бы трудно заметить.
Каждая группа разработчиков получает набор требований к своей части системы, включая точное описание её функциональности и предельные требования к процессорному времени, занимаемой памяти, места на диске и т. д.
[править] Взаимодействие
Чтобы предотвратить катастрофу, группы разработчиков должны взаимодействовать друг с другом всеми возможными способами. Вместо того чтобы строить предположения по поводу реализуемой им функции, разработчик должен задавать архитектору уточняющие вопросы, поскольку предположения могут оказаться совершенно неверными.
[править] Пилотная система
Перед тем как разрабатывать окончательную систему, необходимо разработать пилотную систему. Пилотная система выявит ошибки в проектировании, после чего она должна быть полностью переделана.
[править] Хирургические группы
Разумно, если в группе разработчиков есть один "хороший" программист, реализующий самые критические части системы, и несколько других, помогающих ему или реализующих менее критические части. Так делаются хирургические операции. Кроме того, по мнению Брукса, лучшие программисты работают в 5-10 раз быстрее остальных.
[править] Специализированные утилиты
Вместо того, чтобы каждый программист писал собственные утилиты, в каждой группе разработчиков должен быть один программист, ответственный за написание утилит для своей группы (например, генератор кода, создающий код в соответствии с какими-то спецификациями). Должна быть также группа, создающая утилиты для всех работающих над данной системой.
[править] Версии и замораживание системы
По мере создания системы, требования пользователя к ней могут меняться под влиянием его опыта работы с незаконченной системой. Эти пожелания пользователя следует учитывать, но только до какого-то момента, иначе работа над системой никогда не будет закончена. После этого спецификации замораживаются, и все последующие требования изменений откладываются до начала работы над следующей версией.
[править] Снижение стоимости разработки
Брукс приводит 2 способа снизить стоимость разработки программного обеспечения:
- Нанять программистов только после того, как построена архитектура системы. Эта стадия может занять несколько месяцев, в течение которых программистам будет нечего делать.
- Купить часть программного обеспечения у других разработчиков.
[править] Ссылки
 |
Это незавершённая статья о книге. Вы можете помочь проекту, исправив и дополнив её. |
