Мифический человеко-месяц или как создаются программные системы
Добавить в закладки К обложке
- Посвящение издания 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
Глава 8 Объявляя удар
Практика — лучший учитель.
ПУБЛИЙ
Опыт — дорогой учитель, но для глупцов иного нет.
АЛЬМАНАХ БЕДНОГО РИЧАРДСА
(Бедный Ричард — образ необразованного, но здравомыслящего доморощенного философа, созданный Бенджамином Франклином, издававшим в 1732 — 1757 годах ежегодный альманах и использовавшим этот псевдоним (примеч. перев.)).
Сколько времени потребует задача системного программирования? Сколько сил понадобится? Как можно это оценить?
Ранее я предложил соотношения, которые можно применять для времени планирования, написания программ, тестирования компонентов и тестирования системы. Во-первых, нужно сказать, что нельзя делать оценку всей задачи, оценивая только часть, относящуюся к написанию программ, а затем применяя соотношения. Написание программ составляет лишь одну шестую часть задачи или около того, и ошибки при его оценивании или в соотношениях могут привести к смехотворным результатам.
Во-вторых, нужно учитывать, что оценки, полученные при создании отдельных небольших программ, нельзя применять для больших системных продуктов. К примеру, для программы, насчитывающей 3200 слов, Сакман, Эриксон и Грант оценивают суммарное время написания программ и отладки для одного программиста в 178 часов, что экстраполируется до 35800 операторов в год. Вдвое меньшая программа потребовала меньше четверти указанного времени, что при экстраполяции дает производительность, близкую уже к 80000 операторам в год.[1]Необходимо добавить затраты времени на планирование, составление документации, тестирование, системную интеграцию и обучение. Линейная экстраполяция данных, относящихся к коротким задачам, бессмысленна. Если экстраполировать время, за которое можно пробежать стометровку, то окажется, что можно пробежать милю менее чем за три минуты.
Прежде чем отказаться от этих данных, отметим, что и для не совсем сравнимых задач они показывают, что объем работы растет как степенная функция размера, даже без учета процесса отмена информацией (кроме программиста с собственной памятью).
Показанные на рис. 8.1 данные вызывают грустные чувства. График демонстрирует результаты, полученные в исследовании, проведенном Нанусом (Nanus) и Фарром (Farr)[2]в System Development Corporation. В нем выявляется зависимость с показателем степени 1,5:
Объем работы = (константа) Ч (количество команд) ^ 1.5.
В другом исследовании, проведенном в этой компании, о котором сообщает Вайнвурм (Weinwurm)[3], также получен показатель, близкий к 1,5.
Есть несколько исследований относительно производительности труда программиста, в которых предложен ряд технологий оценивания. Есть обзор опубликованных данных, подготовленный Моурином (Morin).[4]Я приведу здесь лишь несколько наиболее показательных результатов.
Рис. 8.1 Затраты на программирование как функция размера программы
Данные Портмана
Чарльз Портман (Charles Portman), менеджер отдела программирования ICL — Computer Equipment Organization (Northwest) в Манчестере, предлагает свое понимание проблемы, которое может оказаться полезным.
Он обнаружил, что его команды программистов отстают от графиков примерно наполовину, т.е. каждое задание выполняется примерно вдвое дольше, чем предполагалось. При этом оценки очень тщательно проводились группами опытных экспертов, оценивавших в человеко-часах трудоемкость нескольких сотен подзадач с помощью диаграмм ПЕРТ. Когда выявлялось отставание от графика, он просил вести подробные ежедневные журналы использования времени. Из них выяснилось, что ошибка оценок полностью объясняется тем, что его команды использовали на программирование и отладку лишь 50 процентов рабочего времени. Остальное время терялось из-за отказов машины, на небольшие срочные посторонние задания, совещания, писание бумаг, дела фирмы, болезни, личное время и т.д. Короче оценки исходили из нереалистичного предположения о том, какая часть рабочего времени отводится непосредственно работе.[6]
Данные Арона
Джоэл Арон (Joel Aron), менеджер IBM по системным технологиям в Гейтерсберге, штат Мэриленд, изучал эффективность труда программистов во время работы над девятью крупными системами (крупная соответствует более чем 25 программистам и 30000 операторов).[7]Он классифицирует такие системы в соответствии с интенсивностью взаимодействия между программистами (и частями системы) и обнаруживает следующие величины производительности:
- 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
В конце февраля 2009 года в продаже на Amazon появилось долгожданное устройство для чтения электронных книг Kindle 2. Это событие вызвало бурю негодов
Электронная читалка - вещь очень хрупкая. Если с ней обращаться не правильно - она может сломаться. Чтобы этого не случилось, нужно придерживаться лиш
Большинство книг в сети интернет распространяется в формате FB2 (Fiction Book). Этот формат очень удобен для чтения. Файлы, в нем созданные, отличаютс
Популярность электронных книг у читателей неуклонно растет. Для доказательства этого мы провели маленький эксперимент. Из 10 людей, читающих в метро,
Файлы формата FB2 часто можно увидеть среди огромнейшего разнообразия текстовых форматов. Такая высокая популярность объясняется его предназначением.
Первую версию формата PDF (Portable Document Format) еще в 1993 году разработала фирма Adobe Systems. В 2006 году она уже разработала версию 1.7, а с
Фирма Apple порадовала пользователей iPad, выпустив под него красивую и удобную читалку iBooks.