Фред Брукс и «Мифический человеко

Фред Брукс и
«Мифический человеко-месяц»
Фредерик Филлипс Брукс Младший
• Родился 19 апреля 1931 в городе Дарем, Северная Каролина
• 1953 год – окончил Университет Дьюка
• 1956 год – получил титул Ph.D. по прикладной математике в
Гарвардском университете. Научный руководитель – Говард
Эйкен.
• 1956-1964 – работа в IBM
• 1964 – основал факультет информатики в Университете
Северной Каролины
• 1994 – призван членом в Ассоциацию Вычислительной Техники
(ACM)
• 1999 – награжден Премией Тьюринга
2
3
Мифический человеко-месяц или
Как создаются программные системы
• Книга об управлении проектами в области разработки
программного обеспечения
• Основана на опыте работы в IBM, полученным в ходе
управления проектом по созданию операционной системы
OS/360
• «Библия для программной инженерии»: «все её читали, но
никто ей не следует!»
• Издана в 1975 и в 1995 году
4
Системный программный продукт
5
Причины провалов
• Программные проекты чаще проваливаются из-за нехватки
календарного времени, чем по всем остальным причинам
вместе взятым.
• Допущение, что все будет хорошо — каждая задача займет
столько времени, сколько "должна" занять
• Человеко-месяц — неподходящая единица измерения объема
работ
6
Человеко-месяц
Полностью разделяемая задача
Задача с обменом данными
Неделимая задача
Задача с интенсивным взаимодействием
7
Действия при срыве графика
8
Действия при срыве графика
9
Закон Брукса
Если проект не укладывается в
сроки, то добавление рабочей
силы задержит его еще больше.
10
Особенности оценки
Объем работы = (константа) х (количество команд)1,5
Зависимость от взаимодействия:
• Очень слабое взаимодействие: 10000 инструкций на человека в
год.
• Некоторое взаимодействие: 5000 инструкций на человека в год.
• Существенное взаимодействие: 1500 инструкций на человека в
год.
Только около половины времени отводится непосредственно работе
11
Отставание от графика
• Как оказывается, что проект отстает на год? Сначала он отстает
на один день…
• До начала работы оценки продолжительности работы почти не
меняются
• Завышенные оценки уменьшаются
• Заниженные оценки почти не меняются практически до конца
проекта
12
График
• Чтобы управлять большим проектом по жесткому графику,
прежде всего, надо иметь график.
• Вехи должны быть четко определены
• Метод критического пути, диаграмма PERT показывает
критические участки, задержка которых приведет к задержке
всего проекта
13
Эффект второй системы
• Общая тенденция заключается в перегруженности
проекта второй системы идеями и
украшательствами, благоразумно отложенными в
сторону при работе над первым проектом.
• Самодисциплина – способ избежать эффекта.
14
Планирование на выброс
• Первая версия системы как правило оказывается
малопригодной для использования
• Планируйте выбросить первую версию – вам все
равно придется это сделать
15
Сопровождение
• Общая стоимость сопровождения широко используемой
программы обычно составляет 40 и более процентов стоимости
ее разработки.
• Исправление ошибки часто влечет появление новой:
• Два шага вперед, один назад
• Разрушение структуры программы:
• Шаг вперед, шаг назад
16
Концептуальная целостность
• Лучше убрать из системы отдельные необычные возможности и
реализовать единый набор конструктивных идей, чем оснастить
ее многими хорошими, но невзаимосвязанными и
несогласованными идеями.
• Разделение архитектуры и реализации.
• Небольшое число разработчиков.
17
Операционная бригада
Распределение ролей:
• Хирург
• Второй пилот
• Администратор
• Редактор
• Секретари
• Делопроизводитель
• Инструментальщик
• Отладчик
• Языковед
18
Документация
• Руководство – внешняя спецификация продукта.
• Способы описания: естественный язык и формальные
определения.
• Можно использовать оба способа, но один должен быть
главным а другой – производным.
• Внесение изменений в руководство: конференции и «сессии
верховного суда»
19
Способы взаимодействия
• Неформально
• Совещания
• Рабочая тетрадь – структурированная совокупность всех
документов, созданных во время выполнения проекта.
• Журнал регистрации телефонных звонков.
20
Документация
Необходимая документация для пользователя:
• 1. Назначение.
• 2. Среда.
• 3. Область определения и область значений.
• 4. Реализованные функции и использованные алгоритмы.
• 5. Форматы ввода-вывода.
• 6. Инструкция по работе.
• 7. Опции.
• 8. Время работы.
• 9. Точность и проверка.
21
Документация
Для разработчика:
• 1. Блок-схема или граф подпрограммной организации.
• 2. Полные описания используемых алгоритмов или ссылки на
такие описания в литературе.
• 3. Разъяснение структуры всех используемых файлов.
• 4. Организация прохождения данных - последовательность, в
которой данные или программы загружаются с ленты или диска
и описание того, что делается на каждом шаге.
• 5. Обсуждение модификаций, предполагаемых исходным
проектом, сущность и расположение добавочных блоков и
выходов.
Способ организации документации: самодокументирующиеся
программы.
22
Нисходящее проектирование
• Разработка как последовательность
уточняющих шагов.
• Позволяет раньше начать
тестирование.
23
Структурное программирование
• Применение ветвлений с помощью GO TO образует
структуры, располагающие к появлению логических
ошибок.
• Операторов цикла DO WHILE и условия
IF THEN ELSE достаточно.
24
Сложности программирования
• Существенные задачи моделирование сложных
концептуальных структур, составляющих
абстрактный программный объект.
• Второстепенные задачи - создание представлений
этих абстрактных объектов с помощью языков
программирования и отображение их в машинные
языки.
• Существенные трудности: сложность,
согласованность, изменяемость и незримость.
25
Серебряной пули нет
Нет ни одного открытия ни в технологии, ни в методах
управления, одно только использования которых
обещало бы хоть на порядок величин повысить
производительность, надежность, простоту.
Три наиболее крупных шага:
• Языки высокого уровня
• Разделение времени.
• Объединенные среды программирования.
26
Серебряной пули нет
Кандидаты на роль пули:
• ADA и другие языки.
• Объектно-ориентированное программирование
• Экспертные системы и искусственный интеллект
• Автоматическое программирование
• Графическое программирование
• Верификация
• Среды и инструменты.
Итог по пулям: положение прежнее.
27
Мифический человеко-месяц
20 лет спустя
• Модель пошагового создания вместо
планирования на выброс.
• Сокрытие информации.
28