Текст книги "Программное обеспечение и его разработка"
Автор книги: Джозеф Фокс
Жанр:
Базы данных
сообщить о нарушении
Текущая страница: 17 (всего у книги 21 страниц)
В последних категориях следует ожидать намного большего числа строк программ, чем в первой. Диаграмма, иллюстрирующая эти различия, приведена на рис. 6.16.
Определение человеко-месяца
В подсчеты с помощью человеко-месяцев (ЧМ) включаются все участники, поддерживающие разработку программного обеспечения от начала работы над проектом и до выпуска в свет готовой системы. Работники, проводившие анализ требований, проектировщики, секретари, руководители, библиотекари, охрана – все они должны учитываться (пропорционально вкладу в создание программного обеспечения) при подсчетах в человеко-месяцах. Некоторый процент от человеко-месяцев, отнесенных к инженерной части, должен быть подсчитан как вклад в программное обеспечение, точная доля определяется совместно руководством технической частью проекта и разработкой программного обеспечения. Необходимо учесть все часы, занятые работой над проектом, от самого начала до самого конца.
Изменчивость
Не следует думать, что отношение СТП/ЧМ остается постоянным для разных типов программного обеспечения. Создавать тексты для использования в фазе разработки легче, чем для использования на стадии реальной работы. Управляющее, или системное, программное обеспечение (операционное) должно, видимо, быть более сложным, чем прикладное (операционное) обеспечение. Первые варианты могут оказываться более сложными, чем более поздние, так как постепенно приходит опыт, и группы программного обеспечения начинают более эффективно работать именно как группы.
Вопросник по производительности труда
Обратимся теперь к данным, собранным нами в базе данных по производительности труда. Мы хотели выяснить, что же влияет на производительность труда, измеряемую в строках программы, а для этого нам нужно было собирать множество различных данных о проводимой работе. Нам было необходимо знать окружение, в котором работает заказчик. Есть ли у заказчика достаточный опыт для работы в данной прикладной области? Имеется ли у заказчика достаточный опыт в области обработки данных или хотя бы вообще по автоматизации? Участвовал ли заказчик в составлении проекта? В определении требований? В разработке программ? Было ли взаимодействие с заказчиком очень сложным или его можно отнести к средней сложности?
Мы хотели знать «цену проекта», его оцениваемую стоимость. Не требовали ли от нас больше разных переездов, чем это вызывалось необходимостью? Находилась ли группа в непосредственной близости от заказчика? Было ли место расположения разработчиков «хорошим»? Или плохим? (В одной крупной разработке нам приходилось возить программистов по утрам за 50 миль, а по вечерам привозить, их обратно, для того чтобы они смогли получить доступ к машине, на которой проводилась разработка, и вступать в контакты с заказчиком.) Не было ли так, что машинное время выделялось только с полуночи до 4 ч утра?
Мы хотели знать долю программистов-разработчиков, участвовавших в составлении проекта. Нам хотелось знать максимальную скорость работы, точнее, насколько хороша была программистская группа – действительно хорошая, средняя или плохая. Была ли документация по требованиям скудной, средней или пространной? Был ли «стабильным» проект? Кто предлагал изменения – пользователи или разработчики? Какой использовался язык? Какими ресурсами обладала машина, на которой работала система? Какие вычислительные машины использовались во время разработки? Не велись ли параллельные работы по разработке аппаратуры вычислительной машины, на которой должна была действовать система? Затем нам нужно было узнать о методах, которые применялись руководством работ.
Был ли составлен план, использовался ли он для:
– оценки изменений в проекте системы и внесения этих изменений
– оценки изменений в проекте программного обеспечения: и их внесения
– тестирования (на всех уровнях)
– извещений об ошибках в программах, выявленных и исправленных
– использования вычислительных машин
– разработки вспомогательного вычислительного оборудования
– защиты важнейшей информации
– контроля денежных затрат
– руководящего контроля
– документирования
– стандартизации методов кодирования
Не использовались ли необычные устройства ввода/вывода или средства отображения? Не было ли это оборудование использовано каким-либо необычным образом? Работала ли программистская группа на данной машине прежде? На этом же языке? С приложениями таких же размеров и сложности? Работали ли ведущие программисты прежде того в совместных проектах? Каково было окружение разработки? Работа велась с выделением пультового времени? Или в режиме разделения времени? Использовались ли удаленные терминалы? Привлекались ли программисты к непосредственной работе на машине? Каким было время ожидания решения? Применялся ли диалоговый режим? Как долго? Менее 2 ч, от 2 до 7 ч, от 8 до 24 ч, более 24 ч? Какая доля программ разрабатывалась с использованием:
– библиотеки инструментальных программ,
– программного библиотекаря,
– структурного программирования,
– сквозного контроля,
– программирования сверху вниз,
– метода главного программиста?
После этого мы приступили к оценкам сложности:
– приложений,
– алгоритма программ,
– межпрограммных связей,
– внешних связей,
– структуры базы данных.
Какая доля программ пришлась на:
– нематематические приложения и форматирование ввода/вывода,
– математические и вычислительные программы,
– программы управления центральным процессором и вводом/выводом,
– программы возвратов и восстановления после сбоев?
Какие ограничения повлияли на проект:
– в оперативной памяти,
– временные,
– возможностей ввода/вывода?
Проводилась ли классификация программ? Из скольких модулей они состояли? Сколько классов было в базе данных? Сколько страниц в документации? Сколько в рабочей? А сколько в сопроводительной? Сколько памяти занимает операционная система при выполнении программ? Нам нужно было составить хронологическую таблицу обнаружения ошибок с данными по разным категориям. Нам, конечно же, хотелось иметь сведения о численности персонала, занятого в:
– управлении,
– администрации,
– программировании,
– анализе,
– технических работах.
Нам был необходим список вычислительных ресурсов. Нам нужно было знать, какие усилия были потрачены на интерпретацию и моделирование.
Очевидно, что сбор всех этих данных еще больше усложнил и без того сложный процесс управления разработкой программного обеспечения. Часто мои подчиненные говорили мне, что у меня есть два варианта – я могу составить график или провести исследование и получить данные, нужные для работы. Еще чаще никаких данных получить я не мог. Но, хотя и медленно, с годами эти сведения приходили. Приводя список большинства этих вопросов, я хотел показать, что существует так много переменных и разных мнений, что указание любого одного элемента производительности труда в качестве доминирующего будет сверхупрощенным. Прежде чем мы сможем использовать нашу базу данных как средство управления при предсказании производительности труда, нам необходимо собрать огромное множество сведений о разработке программного обеспечения для сотен и сотен разных проектов.
Ошибки при подсчете СТП
Наиболее широко распространенная ошибка, возникающая в связи с подсчетами числа строк программ, заключается в игнорировании творческой стороны дела и придании особой важности подсчетам и вознаграждению людей за показатели в строках программы за человеко-месяц! Многие руководители загипнотизированы этими подробностями и забывают об изобретательской и творческой активности.
Многие люди, измеряя человеко-месяцы, ошибочно подсчитывают только время, затраченное программистами. Мы уже видели, что в очень больших проектах более 50 % всех усилий предпринимается группами сопровождения и управления. Это тоже прямые затраты, их также необходимо учитывать.
Большой ошибкой является подсчет числа СТП за человеко-месяц уже в середине разработки. Если вы оценили полное число строк программы и среднее число строк за человеко-месяц и «заключили соглашение» на выполнение работ, вы должны постараться не впасть в ошибку «измерений в середине». Не следует считать уровень производительности труда, достигнутый на каком-то этапе, постоянным и использовать его для расчета производительности труда на последующих этапах.
Как-то у нас был контракт на западном берегу, в котором мы недооценили объем программ примерно вдвое. Мы сменили руководителя – и новый не хотел отвечать за чужие грехи. Спорить с этим было трудно.
Этот новый руководитель утверждал, что наши цифры по производительности труда также были неверными. Он взял производительность в момент времени х (см. рис. 6.17) и заявил, что он попытается достигнуть именно такой же производительности для всего проекта в целом.
Рис. 6.17. Изменения отношения строк текста программы к человеко-месяцам во время работы над программным обеспечением для проекта
Это так же неверно, как и использование скорости работы в точке (у) в качестве уровня, который будет достигнут начиная с самого первого дня. Мы должны пользоваться средним значением.
Выбирать уровень в какой-то определенный момент времени – значит, впадать в серьезную ошибку! Единственно, когда можно измерить число строк программ, написанных для проекта, это в конце, после завершения всех работ. Не существует никаких цифр, на которые можно было бы вполне положиться вплоть до самого конца. Имеют смысл только полные подсчеты, а не промежуточные.
В самом деле, в проекте для Западного берега мы предсказывали, что первые написанные программы (системное программное обеспечение) отнимут гораздо больше времени и сил в расчете на одну СТП, чем последние. Нам возражали, заявляя, что уровень, достигнутый на ранней точке х, будет оставаться на постоянном уровне в течение всей работы.
Уровень производительности труда при создании программного обеспечения, достигнутый в некоторый момент работы, не следует использовать как постоянную для расчета будущей производительности. Производство строк программы не остается постоянным. Оно начинается достаточно медленно (с нуля), резко поднимается, а затем снова спадает до нуля.
Закон больших чисел. Из приведенного списка вопросов становится совершенно ясно, что число переменных, играющих роль в их решении, очень велико. Из этого следует, что реальное изучение информации, собранной в базе данных, не может быть проведено очень быстро. Когда я ушел из фирмы IBM в 1977 году, эти данные были еще слишком отрывочными. Во избежание вводящих в заблуждение статей и выводов, я придал данным статус «собственности компании». Из этого было лишь одно исключение.
Неверная интерпретация содержимого базы данных. В начале 1977 года я допустил публикацию одной статьи в журнале IBM System Journal, написанную Уолстоном и Феликсом с условием, что будет опубликована только часть данных и что будет ясно указано, что приводимый анализ является предварительным. И тем не менее статью часто цитируют, как будто это окончательный отчет, и это цитирование не всегда верно.
В статье утверждалось следующее[37]37
Walston С. Е. and Felix С. P. A Method of Programming Measurement and Estimation, IBM Sym. J, 16, № 1 (1977), 54–73.
[Закрыть]:
Данные были собраны по шестидесяти завершенным разработкам программного обеспечения. Использовалось двадцать восемь разных языков программирования. 28 языков для 66 различных вычислительных машин. Размеры программ изменялись в диапазоне от 4000 строк исходного текста до 467 000.
Рабочие программы в статье не рассматриваются; сведения касаются только исходных программ. В статье приводится список 29 переменных из 69 представленных в отчетах, отбирались переменные, в наибольшей степени влияющие на производительность труда. В статье полностью игнорировались взаимодействия между этими 29 переменными. Там говорилось, что «анализ переменных проводился независимо друг от друга, возможность корреляции переменных и эффекты этого взаимодействия во внимание не принимались». Таблица 3, приведенная в статье, имела такую первую строчку:
| Строки исходной программы за один человеко-месяц | 274 | 150–440 |
Теперь мне хочется дать свои комментарии по поводу этой статьи. Рассмотрено менее одного завершенного проекта в расчете на одну вычислительную машину. Каждый из рассмотренных языков применялся в 2.1 проекте. Различия в масштабах были даже большими, чем от 4000 до 467 000 строк. Космические проекты Хьюстона были разделены на несколько «программ», каждая из которых имела отдельный отчет. Но работать по отдельности они не могли.
В одной таблице были сведены средние (медианные) значения отношения числа строк к человеко-месяцам; таблица, показывавшая 29 наиболее важных переменных, содержала именно средние значения. В табл. 3, приведенной выше, отбрасывались верхние и нижние 25 % значений. Все это делало данные гораздо более регулярно выглядящими, чем это есть на самом деле. Цифры, собранные на стр.291 в графе оценок производительности, показывают невероятно широкий диапазон производительности, это осталось для нас непонятным.
В статье не рассматриваются рабочие программы. Но именно они являются результатом работы, а не исходные программы. В базе данных есть сведения по рабочим программам. Игнорировать рабочие программы, значит также игнорировать коэффициент повышения производительности, вносимый языками высокого уровня. Язык программирования не вошел в 29 наиболее важных факторов. Но так дело обстоит только в статье, а не в реальной жизни. Кстати говоря, среди того, что особенно поразило нас после того, как мы впервые просмотрели базу данных, была доля программных проектов, в которых все еще использовались ассемблеры. Таких было более 50 %.
Многие из рассматривавшихся 60 проектов были повторными реализациями, проводившимися теми же группами.
В статье говорится, что никакие взаимовлияния переменных не рассматриваются. Но ведь очевидно, что такое взаимодействие существует!
В статье предполагается, если не прямо утверждается, что фактором, влияющим на производительность в наибольшей степени, является «сложность взаимодействия с заказчиком». Таблица содержит строку с таким заголовком и некоторые числа; никаких комментариев в тексте нет. Известно, что учитывались отчеты, поступившие с разных концов света. База данных составлялась в Гейтсбурге, шт. Мэриленд, – крупнейшие разработки проводились в Хьюстоне, шт. Техас; Атлантик-Сити, шт. Нью-Джерси; Лос-Анджелесе, шт. Калифорния; а также в Моррис-Плейне, шт. Нью-Джерси. Мы решили, что оценить фактор взаимодействия с заказчиком иначе, как заявив, что он выше «нормальной сложности», невозможно. Нам не удавалось сравнить мнения руководителей из Техаса с мнением руководства в Лос-Анджелесе или в Сайгоне, или в Токио. Их мнения были чересчур личными.
Я не верю в то, что сложность взаимодействия с заказчиком была или остается наиболее важным фактором, воздействующим на производительность. Слишком недостаточны данные, которыми мы располагаем, чтобы можно было делать такой вывод.
Я видел три документа – книгу, авторский экземпляр и статью, в которых данная статья цитировалась неверно! В этих документах утверждалось, что «фирма IBM говорит то-то и то-то». IBM никогда этого не говорила.
И все же собранная в IBM база данных стала наиболее ценным источником. Фирме следует продолжить публикацию дальнейших открытий, не взирая на риск быть неправильно понятой.
Я разрешил эту публикацию в 1977 году; я отвечаю за большую часть всех недоразумений, о которых я уже рассказал.
Сейчас можно сказать, что публикация статьи была ошибочной. Подразумевалось, что это будет промежуточный отчет о незавершенных, но весьма значимых исследованиях. Она неправильно интерпретируется, но может быть более хладнокровные люди сумеют извлечь ценные сведения из этих данных, полностью отдавая себе отчет в том, что сведения имеют предварительный характер.
Хорошей базы данных, из которой можно было бы извлекать достоверные сведения, в настоящее время не существует. Данные, имеющиеся в нашем распоряжении, поразительнейшим образом отличаются по уровню достигнутой производительности труда, а почему это так, мы не понимаем. Уровни производительности труда в рамках одной и той же работы могут доходить от 100 °СТП за человеко-месяц до 6 °СТП за человеко-месяц. Мы до сих пор не понимаем причины таких расхождений.
Проведение подобных замеров обходится дорого, но если мы надеемся полнее разобраться в динамике процесса производства программного обеспечения, мы должны продолжать сборы такого рода информации. До тех пор, пока не будет собрано достаточно большое количество данных со всеми необходимыми подробностями, мы не можем считать, что полностью овладели процессом разработки программного обеспечения.
До тех пор, пока этого не сделано, идея использования «баз данных» истории проектов для предсказания денежных и других затрат остается совершенно наивной. Она совершенно бессмысленна; воздействующих факторов слишком много.
Рис. 6.18. Зависимость производительности труда от числа строк создаваемой исходной программы.
Множество чисел, интерпретируемых как чисто случайные.
Рис. 6.18 заимствован из исследования Правительства США, посвященного изучению соотношения числа строк сдаваемой исходной программы (ЧССИП) и производительности (СТП/ЧМ). Заметьте, что по обеим осям разметка нанесена в логарифмическом масштабе. Единственное, что показывают эти данные, это, что никаких полезных оценок на их основании сделать нельзя. Разнообразие их просто поразительно.
Рисунок полезен только тем, что показывает отсутствие у нас достаточного количества данных. На этом графике для программ размером в 100 00 °СТП внутрь области, ограниченной линиями, проведенными на уровне отклонений от – а до +а, попали проекты с коэффициентами и 80 и 800 ЧССИП/ЧМ. Такой разброс не может быть полезным для прогнозирования!
Предупреждение. Использовать строки программ как меру производительности труда и метод оценки в настоящее время просто абсурдно. Неизвестно, каким образом можно сопоставлять реализуемую функцию и строки программы. Если руководство настаивает на повышении скорости создания строк программы, программист всегда может написать «рыхлую», «пухлую» программу, которая сделает хорошими все показатели по производительности труда, но которая абсолютно не подходит для настоящего дела, так как для выполнения такой программы может понадобиться слишком много памяти и процессорного времени. Мне встречалось много таких «хороших» руководителей, требующих от каждого программиста как можно больше строк программ в месяц.
Форма отчетности по строкам программ
Желательно, чтобы отчеты по проектам выглядели как-нибудь так:
Название: Программа наведения ракет: с математическим уклоном; загружается с перекрытием; критическая по времени.
Функции: Расчет курса, скорости и всех управляющих сигналов, необходимых для ведения ракеты к точке перехвата другой ракеты.
| Не включено в программу: | а) Отслеживание всех ракет; делается другой программой. | |
| б) Прием и передача всех сигналов; делается где-то в другом месте. | ||
| Всего выполняемых стп — | 36 441 | |
| в рабочей программе | ||
| Написано СТП (выполняемых) ЯВУ | 7014 | |
| машинный язык | 1314 | |
| Не написано, но выполняется | 8424 | |
| Человеко-месяцев (прямой подсчет) | 340 человеко-месяцев | |
| Программы[38]38
Имеются в виду рабочие программы. [Закрыть], написанные, но не сохраненные (выброшенные) | 26 584 | |
| 8144 Тесты | ||
| 11 240 имитаторы | ||
| 3100 моделирование | ||
| 4100 проч. | ||
| Программы[39]39
Имеются в виду рабочие программы. [Закрыть], написанные и оставленные, но не выполняемые | 50 445 всего | |
| 22 814 тестовые программы последней версии | ||
| 18 416 примечания | ||
| 1114 моделирование | ||
| 8101 варианты данных | ||
| Время от начала работы до сдачи | 18 месяцев | |
| Время первой итерации | Составления спецификации требований | 4 месяца |
| Составления проектной документации | 8 месяцев | |
Этот пример приведен здесь для иллюстрации некоторых принципов, изложенных на предыдущих страницах. Некоторых, но отнюдь не всех. В полную отчетную форму необходимо включать подробные ответы на многочисленные вопросы, в которых, как мы уже установили, мы нуждаемся – какой тип вычислительной машины использовался для трансляции и т. п.
Некоторые результаты сбора статистики
В результате всех этих усилий мы пришли к тому, что никто не способен предсказывать производительность труда для выбранного случайным образом большого программного проекта. Слишком уж много параметров, слишком много качественных факторов, оказывающих значительное воздействие на исход дела. Мы можем оказаться недалеко от истины только для некоторых работ, которые ведутся проверенной группой в хорошо известной прикладной области.
Ниже приводятся некоторые промежуточные результаты замеров, проводившихся в IBM над программными проектами. Работы сгруппированы на основе предсказаний их руководителей по степени трудности. Посмотрите, какие наблюдаются грандиозные различия в производительности труда, измеренной в строках текста программ (СТП) в месяц.
| Маленький/легкий[40]40
Производительность труда, предсказанная руководством проекта. [Закрыть] (300–900) | |
| 1 | 517 |
| 2 | 615 |
| Средний/легкий * (200–600) | |
| 3 | 199 |
| 4 | 39 |
| 5 | 100 |
| 6 | 286 |
| 7 | 524 |
| 8 | 28 |
| 9 | 109 |
| 10 | 167 |
| 11 | 274 |
| 12 | 1071 |
| Средний/трудный* (100–300) | |
| 13 | 562 |
| 14 | 403 |
| 15 | 128 |
| 16 | 81 |
| 17 | 68 |
| 18 | 400 |
| 19 | 253 |
| 20 | 227 |
| 21 | 250 |
| 22 | 163 |
| 23 | 198 |
| Большой/трудный * (50–150) | |
| 24 | 186 |
| 25 | 68 |
| 26 | 284 |
| 27 | 182 |
| 28 | 229 |
| 29 | 46 |
| 30 | 120 |
Оценка
Оценка размеров программы
Если бы нам заранее были известны размеры программ, которые нам предстоит написать, наше положение было бы намного лучше уже с самого начала разработки большого проекта.
Предложив опытному разработчику изучить уже работающие системы, мы могли бы получить хорошие оценки числа строк программы для тех работ, которым можно найти аналоги среди ранее запрограммированных.
Здесь мы со всей очевидностью сталкиваемся с неким порочным кругом: «Вам нельзя доверить работу, у вас нет опыта». «Как же я могу получить опыт, если мне не дают работать?» Наше положение именно таково. Мы хотим, чтобы оценки делались кем-то, кто уже делал это в прошлом. Или делал что-то, похожее на то, что мы пытаемся сделать.
Теперь нам очень пригодятся наши знания о пяти типах использования вычислительных машин и таксономии программного обеспечения. То, что человек имеет опыт разработки крупных прикладных систем, не означает, что он сможет оценить усилия, необходимые для создания системного программного обеспечения. Эта ситуация должна служить вам в качестве предупреждения. Не надо слушать прикладников, пытающихся оценивать трудности системного обеспечения! Не позволяйте людям, разрабатывавшим пакетные программы, оценивать системы реального времени. Это же относится и ко всем другим категориям.
Факторы, определяющие трудность разработки
На усложнение или облегчение разработки влияет сразу целая комбинация факторов. Прежде, чем закончить главу я хочу перечислить 27 из них. Все они разбиваются на три основные категории:
(A) Функция, которую надо выполнить
(B) Окружение в фазе использования
(C) Факторы, действующие в фазе разработки
Трудность разработки программ = (А) × (В) × (С)
Таблица 6.2. Трудности разработки
| + | |||||
| + | + | ||||
| + | |||||
| + | + | ++ | |||
| + | + | + | |||
| + | + | + | |||
| + | |||||
| + | |||||
| + | |||||
| + | |||||
| - | + | + | + + | ||
| + | - | + | |||
| - | + | ||||
| + | |||||
| + | + | + + | |||
| + + | |||||
| + | + | + + | |||
| + | |||||
| + | |||||
| + | |||||
| + | |||||
| + | |||||
| - | |||||
| + | |||||
| + + | |||||
Схема трудности разработок. Таблицу 6.2 можно использовать как справочник, позволяющий определить, на что нужно обращать внимание, приступая к разработке системы. Расставленные в ней оценки «+», «-» – укажут вам, облегчает ли (-) данный фактор разработку или усложняет (+) ее при переходе от систем типов I и II к системам типов III, IV или V. Если на схеме отмечен знак (-), производительность труда будет повышаться, если стоит знак (+), производительность будет ниже. Сначала рассмотрите схему, а затем приступайте к изучению объяснений по каждому из 27 пунктов.
Функциональные факторы
| 1. Функции, количество | Чем больше функций, тем больше нужно написать программ для их реализации. С ростом размеров программ трудность разработки программного обеспечения возрастает нелинейно. |
| 2. Функции, сложность | Программа вычисления коррекции орбиты для полета к Луне в 50 или более раз труднее, чем программа добавления очередного взноса за покупку в месячную кредитную карточку. Управляющие программы логически сложны, а логическая сложность представляет большую проблему, чем сложность научная. |
| 3. Функции, ясность | Некоторые функции (вспомните платежные ведомости) ясны и понятны. Другие находятся лишь в головах старых мастеров, и при попытке записать их на бумаге может возникнуть страшная путаница, а ведь без записи нельзя программировать. Особенно трудно работать с системами типа V. |
| 4. Незамкнутый цикл, человек взаимодействует с работающей системой | Системы, одним из элементов которых является человек, более сложны, чем какие-либо другие. Информацию для человека надо готовить особым образом; ответы, исходящие от него, надо приспосабливать к обстоятельствам; среди этих ответов может наблюдаться значительное разнообразие; человеку надо давать и дополнительную информацию, причем последовательность запросов нельзя сделать достаточно строгой, чтобы не получилось так, что он откажется от пользования системой. |
| 5. Число различных пользователей программы | Разные пользователи по-разному воздействуют и на вычислительную машину и на ее программное обеспечение. Стало аксиомой утверждение, что чем больше пользователей у программы, тем больше ошибок будет в ней обнаружено. Под пользователем понимается не просто отдельная вычислительная установка. Машины и программы для управления ракетами могут располагаться в сотнях различных мест, но способ использования у всех будет один и тот же. |
| 6. Число запусков программы | Если программа должна работать постоянно, нам надо позаботиться об эффективности (сколько аппаратуры необходимо для ее выполнения) в фазе использования. Если программа будет выполнена лишь единожды, ее эффективность не должна нас особенно волновать. |
| 7. Число машин, на которых будет выполняться данная программа | Если разрабатываемая программа будет выполняться только на одной машине, нам можно несколько меньше обращать внимания на используемые ею машинные ресурсы. Программа для радиолокатора, выполняемая на сотнях вычислительных машин, на сотнях кораблей, должна быть до предела отточена и сжата. Лишние затраты памяти будут умножаться в сотни раз. |
| 8. Функции и их взаимодействия | Некоторые сложные задачи весьма слабо взаимодействуют со всеми другими задачами, которые решаются на той же машине; другие же имеют настолько тесные связи, что оказываются буквально переплетенными. |
| 9. Элементы данных | Число и размеры элементов данных, их разнообразие, их взаимодействия, их изменчивость, все это может иметь огромное влияние на размер программы и на трудности, возникающие в фазе проектирования. Брукс замечает: «Покажите мне свои данные, и я смогу больше рассказать о вашей программе, чем в том случае, если мне покажут блок-схемы». |
| 10. Ожидаемая частота внесения изменений в программу | Если моя программа стабильна, т. е. изменяется не слишком часто, мне можно строить ее совершенна иначе, чем в том случае, когда я ожидаю, что она будет часто подвергаться изменениям. |
| 11. Взаимодействие с другими системами | Если наша вычислительная система должна полностью находиться в распоряжении каких-либо других систем, мы должны обязательна программировать так, чтобы учесть все типы возможных прерываний. |
| 12. Доступная мощность ЦП | Для выполнения задания каждая программа использует ЦП. Некоторые программы используют его более эффективно, чем другие. Когда ресурсы ЦП оказываются недостаточными, программистов просят так провести проектирование программ, чтобы они не просто выполнили задание, но выполнил его с учетом заранее описанных ограничений недостаточных ресурсов ЦП. И программисты пробуют и проверяют свою работу, и пробуют снова и снова. Программы будут работать, но с точки зрения времени программирования, это стоит очень дорого. |
| 13. Доступные пути ввода/вывода | Логически эта проблема не отличается от работы в условиях недостатка ресурсов ЦП, но в данном случае наибольшая потребность возникает в числе путей, по которым данные передаются в машину и из нее. Много стараний должны приложить программисты, чтобы передать весь поток данных через небольшое число «портов», имеющихся в машине. |
| 14. Доступная основная память | Опять та же проблема, но уже со стороны памяти. Для хранения программ требуется память, а если памяти не хватает, программист должен «подкачивать» программы в основную память для выполнения и затем откачивать их во вспомогательную память. Для этого приходится затрачивать как время, так и опять-таки пространство. Может быть и другой вариант, в котором приходится втискиваться в отведенные рамки, создавая проект, а затем снова пытаются втиснуться в них. В 1946 году фон Нейман написал в одной из своих работ, что память является ключом к производительности. Это верно и в наши дни; скорость работы с памятью и ее объем есть критические величины. |
| 15. Доступная вспомогательная память | Еще раз та же самая проблема; на этот раз со стороны вспомогательной памяти. |
| 16. Надежность/Последствия отказов | Двухдневный отказ в системе типа I может быть вполне допустимым. Конечно, он причинит неудобства, но катастрофы за собой не повлечет. Однако, ни часовой, ни 10-минутный сбои нельзя допускать ни в системе управления авиалиниями, ни в системе управления полетом космического корабля, ни в системе противоракетной обороны. Если последствия отказов значительны, нельзя пользоваться стандартной операционной системой (распространяемой поставщиками аппаратуры). Та же проблема возникает и в системах реального времени. В этих случаях либо пишут новую операционную систему, либо модифицируют старую. |
| 17. Ограничения реального времени | Если печать платежной ведомости длится 2.5 ч. вместо запланированных 2 ч, кого это по-настоящему волнует? Возникает лишь легкая досада. Но, если радиолокатор поворачивается за 6.4 с, вычислительная машина обязана принять от него данные, закончив к этому времени обработку предыдущей порции. Если этого не будет, система переполнится. В системе реального времени стандартная операционная система применяться не может. Сколько разных объектов может отслеживаться одновременно? Сколько заданий необходимо завершить перед тем, как приступать к решению новой задачи? Чем больше возможностей и необходимости такого рода, тем больше приходится создавать системных программ для управления потоком данных и содержания его в порядке. Примеры: системы разделения времени; управляющие и командные системы; системы диспетчеризации воздушного транспорта. |
| 18. Адекватность операционной системы | Производители вычислительных машин обычно выпускают или сдают в аренду, или продают большие операционные системы вместе с аппаратурой, которая помогает распределять и управлять работой различных аппаратных компонентов вычислительной машины Однако эти операционные системы могут не вполне подходить для разработки программного обеспечения. |
| 19. Время, выделенное на создание программного обеспечения | Временной график становится доминирующим фактором в большинстве современных систем типа V. Причина кроется в том, что вычислительная машина и ее программное обеспечение обычно представляют собой лишь часть некоторой сложной системы. Спутники, корабли, оружие, ракеты, здания, фирмы – все это может задавать общий темп – а программное обеспечение должно быть готово одновременно с другими частями системы. Обычно график выдерживается – естественно за счет тех функций, которые надо выполнять. Сдается меньший набор функций, чем планировалось заранее, а недостающие вводятся в систему в более поздние сроки. |
| 20. Доступность средств разработки | Средства создания программного обеспечения, как и любой другой инструментарий, существенно воздействуют на производительность труда. Перед тем, как новую машину начнут использовать в качестве инструмента, ее тщательно изучают. Богатый набор мощных средств значительно повышает производительность труда. |
| 21. Доступность машин для разработки программ | Этот пункт имеет два аспекта. Во-первых, люди, строящие системы, понимают, что без вычислительной машины при разработке программного обеспечения обойтись очень трудно. Когда машины нет, либо она недостаточно мощна, все страшно замедляется. В то же время люди, незнакомые с ситуацией, не понимают того, что вычислительная машина представляет собой основное средство разработки во всем процессе создания программного обеспечения. Машина на стадии разработки используется столь же интенсивно, как и на стадии использования. Ну и конечно же машина необходима для тестирования программного обеспечения. |
| 22. Знакомство группы, проводящей программирование, с аппаратурой | Во всех областях человеческой деятельности нужно отводить время на приобретение опыта, это же относится и к программированию. Если наша группа программистов уже работала с данной аппаратурой, значит в прошлом она уже приобрела опыт, и от этой группы можно ожидать работы с большей производительностью труда. |
| 23. Знакомство группы, проводящей программирование, с разработкой программного обеспечения | Время на приобретение опыта, которое, как мы видели, нужно для работы с аппаратурой, нужно и для изучения инструментального программного обеспечения. |
| 24. Число модулей | Число модулей и связей между ними относится к ряду факторов, значительно влияющих на сложность выполняемой работы. Эта область сходна с пунктом «функции, их взаимодействия», но имеет и отличие от него в том смысле, что число модулей не обязательно связано с числом функций, поскольку количество модулей связано с методикой проектирования программ, а количество функций неотъемлемо от выполняемого задания. |
| 25. Стабильность средств программного обеспечения | Если средства создания программного обеспечения подвержены изменениям, этот и без того сложный процесс еще усложняется дополнительными, часто случайными проблемами. Примером может служить транслятор, в котором есть ошибки и который поэтому создает неправильные рабочие программы. |
| 26. Стабильность аппаратуры | Если используемая в фазе выполнения вычислительная машина находится в состоянии доводки, программисты часто не могут разобраться, где находится ошибка, в программе или в аппаратуре. Это вносит постоянную путаницу. Это, пожалуй, наихудшая из всех ситуаций, с которыми может столкнуться группа, разрабатывающая программное обеспечение. |
| 27. Квалификация пользователя | Пользователь есть настоящий заказчик и важнейшее звено группы разработки. Пользователь, ранее работавший с системой типа V, уже прошедший через весь этот процесс, является наилучшим из всех возможных партнеров разработчиков. Неопытный пользователь может полностью парализовать деятельность прекрасной группы разработчиков, поскольку новоиспеченные пользователи прокладывают себе дорогу к цели урывками. |
В книге «Мифический человеко-месяц» Брукс написал, что системное программирование по крайней мере в три раза труднее, чем программирование трансляторов с языков высокого уровня, которое в свою очередь в три раза сложнее прикладного программирования. Системные программы, которые должны работать в режиме реального времени, в три раза сложнее обычных системных программ. Программы, не имеющие права на малейший сбой, в два или три раза сложнее системных программ. Программы, которые должны работать в диалоговом режиме, по крайней мере в два раза сложнее тех, что работают без диалога.
