Мифический человеко-месяц или как создаются программные системы
Добавить в закладки К обложке
- Посвящение издания 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
Чтобы доверять программе. Описание того, как использовать программу, нужно дополнить описанием того, как убедиться в ее работоспособности. Это означает наличие контрольных примеров.
Каждый экземпляр поставляемой программы должен содержать несколько небольших контрольных примеров, которые можно постоянно использовать, чтобы уверить пользователя в том, что он может доверять программе, и она правильно загружена в машину.
Кроме того, нужны более тщательные тесты, которые обычно выполняются только после модификации программы. Они относятся к трем участкам области входных данных:
1. Основные параметры, проверяющие главные функции программы на обычно встречаемых данных.
2. Примеры на грани допустимого, проверяющие границы области входных данных и убеждающие, что работают наибольшие значения, наименьшие значения и все допустимые исключения.
3. Примеры за границей допустимого, проверяющие границы с обратной стороны и убеждающие, что недопустимые значения вызывают правильные диагностические сообщения.
Чтобы модифицировать программу. Для адаптации или исправления программы требуется значительно больше данных. Разумеется, требуются все детали, а они содержатся в хорошо прокомментированном листинге. У пользователя, модифицирующего программу или редко ее использующего, возникает острая необходимость в ясном отчетливом обзоре, на этот раз внутренней структуры. В такой обзор входят:
1. Блок-схема или граф подпрограммной организации. Подробнее об этом см. ниже.
2. Полные описания используемых алгоритмов или ссылки на такие описания в литературе.
3. Разъяснение структуры всех используемых файлов.
4. Обзор организации прохождения данных — последовательности, в которой данные или программы загружаются с ленты или диска и описание того, что делается на каждом ходе.
5. Обсуждение модификаций, предполагаемых исходным проектом, сущность и расположение добавочных блоков и выходов и дискурсивное обсуждение мыслей автора программы относительно изменений, которые могут оказаться желательными, и как их можно провести. Полезно также изложить его замечания о скрытых ловушках.
Бич блок-схем
Блок-схема чаще всего является лишней частью программной документации. Для многих программ блок-схемы вообще не нужны. Редкие программы требуют блок-схемы более чем на одну страничку.
Блок-схемы показывают структуру принятия программой решений, что является лишь одной стороной структуры программы. Когда блок-схема размещается на одной странице, структура решений выглядит довольно элегантно, но наглядность сразу утрачивается, когда есть несколько страниц, связанных пронумерованными входами и выходами.
Одностраничная блок-схема для значительной по размеру программы становится, в сущности, диаграммой структуры программы и этапов или шагов. В этом качестве она очень удобна. Рисунок 15.1 показывает такой граф подпрограммной структуры.
Рис. 15.1 Граф структуры программы (пример W. V. Wright)
Конечно, такой структурный граф не требует особых усилий по соблюдению стандартов ANSI для блок-схем. Все эти правила относительно вида прямоугольников, соединительных линий, нумерации и т.п. нужны только для понимания подробных блок-схем.
Подробная пошаговая блок-схема является досадным анахронизмом, пригодным только для новичков в алгоритмическом мышлении. Введенные Голдштайном и фон Нейманом [1] прямоугольники вместе со своим содержимым служили языком высокого уровня, объединяя непостижимые операторы машинного языка в осмысленные
группы. Как давно понял Иверсон, [2] в систематическом языке высокого уровня группировка уже проведена, и каждый прямоугольник содержит оператор (рис. 15.2). Поэтому сами прямоугольники являются утомительным и отнимающим место упражнением в черчении и вполне могут быть удалены. Тогда остаются только стрелки. Стрелки, связывающие один оператор с другим, расположенным в следующей строке, излишни, и их можно удалить. Тогда остаются только GO TO, и если придерживаться хорошей практики программирования и использовать блочные структуры для минимизации числа GO TO, таких стрелок окажется немного, но они очень способствуют пониманию. Вполне можно нарисовать их на листинге и вовсе избавиться от блок-схемы.
В действительности о блок-схемах больше говорят, чем пользуются ими. Я никогда не видел опытного программиста, который в повседневной деятельности рисовал бы подробные блок-схемы, прежде чем начать писать программу. Там, где блок-схемы требуются правилами организации, они почти всегда создаются задним числом. Многие гордятся использованием специальных программ для генерации этого «незаменимого инструмента разработки» на основе уже законченной программы. Думаю, что этот всеобщий опыт не является постыдным и предосудительным отходом от хорошей практики программирования, признаваться в котором можно лишь с нервным смешком. Напротив, это результат здравого рассуждения, дающий нам урок относительно полезности блок-схем.
- 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.