В книге «Мифический человеко-месяц» Брукс написал, что системное программирование по крайней мере в три раза труднее, чем программирование трансляторов с языков высокого уровня, которое в свою очередь в три раза сложнее прикладного программирования. Системные программы, которые должны работать в режиме реального времени, в три раза сложнее обычных системных программ. Программы, не имеющие права на малейший сбой, в два или три раза сложнее системных программ. Программы, которые должны работать в диалоговом режиме, по крайней мере в два раза сложнее тех, что работают без диалога.
Основной вклад в стоимость разработки программного обеспечения вносят:
1. Масштаб. Количество реализуемых функций.
2. Ясность. Степень, до которой понятны все реализуемые функции.
3. Логическая сложность. Число условных переходов в расчете на сто команд.
4. Последствия сбоев. Сколько усилий при проектировании и программировании нужно затратить, чтобы удовлетворить всем требованиям по обеспечению надежности и восстановления.
5. Взаимодействия с человеком. Насколько часты и интенсивны взаимодействия с системой.
6. Требования реального времени. Сколь быстро должна быть выполнена нужная функция.
7. Стабильность инструментального программного обеспечения. Достигло ли оно нужного уровня стабильности и зрелости?
8. Стабильность вычислительной машины, на которой будет выполняться система. Достигла ли нужного уровня стабильности вычислительная машина, на которой будет выполняться система.
Это самые главные из 27 факторов, которые мы перечислили выше.
Теперь на примере этих 8 факторов продемонстрируем, как стоимость программ может возрасти с одного доллара за строку до тридцати двух с половиной. Если рассмотреть все 27 факторов и использовать наихудший вариант по всем из них, мы можем получить увеличение стоимости до двухсот долларов за строку.
Числа, которыми я буду тут пользоваться, не являются данными из какого-либо конкретного обзора или исследования. Это приблизительные цифры, основанные на моих собственных суждениях, я их выбрал не из-за их значений, а только для иллюстрации принципа возрастания удельной стоимости программы, и из-за того, что они находятся в полном относительном соответствии друг другу. Я считаю, что сильнее всего удельная стоимость программ увеличивается из-за нестабильности машины, используемой в фазе выполнения. Я приписываю этому фактору коэффициент 20.
В качестве исходной величины я выбираю удельную стоимость программы в 1 доллар за строку текста. В данном примере я буду игнорировать затраты, меньшие этой величины.
Программа, которой нельзя сбиваться, обойдется мне дороже, чем программа, которая выполняет ту же функцию, но при этом допустимы сбои. На сколько же это обходится дороже? Я оцениваю этот фактор — надежность, — коэффициентом 15. Следовательно, если создание «ненадежной» программы стоит один доллар за строку, то надежная программа будет обходиться по 15 долларов за строку.
Каждому из восьми основных факторов я могу приписать такие коэффициенты:
Масштабность (размер) от 1 до 8 Ясность от 1 до 10 Логическая сложность от 1 до 10 Последствия сбоев от 1 до 15 Взаимодействие с человеком от 1 до 5 Требования реального времени от 1 до 5 Стабильность вспомогательного программного обеспечения от 1 до 10 Стабильность вычислительной машины в фазе использования от 1 до 20
В самом плохом случае для всех и каждого из этих восьми факторов стоимость одной строки текста программы будет являться суммой максимальных значений коэффициентов, или 83 доллара за строку.
![]()
Рис. 6.19. Из чего складывалась общая оценка.
Однако в реальной ситуации редко может случиться так, что для каждого фактора будут наиболее неблагоприятные условия. Нужно попробовать оценить относительную трудность каждого из них для конкретной задачи по разработке. На рис. 6.19 приведены мои оценки для пакета программ размером в 10 000 строк для управления ракетой. Эти программы не должны сбиваться, должны обрабатывать данные, поступающие от радиолокатора каждые 4 с, никак не взаимодействовать с пользователем и работать совместно со стабильным вспомогательным программным обеспечением на «вполне стабильной» вычислительной машине. Логическая сложность минимальна, а ясность просто на отличном уровне.
Моя оценка стоимости — 32,5 доллара за строку — была получена суммированием стоимостей, показанных на диаграмме. Я начал с 1 долл. за строку, мне нужно было лишь определить множители.
По моему мнению, коэффициенты надо расставить так:
— множитель для логической сложности отсутствует
— множитель для ясности отсутствует
— множитель для взаимодействия с пользователем отсутствует
— множитель для стабильности вспомогательного программного обеспечения отсутствует
— множитель 5 для размера
— множитель 2,5 для реального времени
— множитель 15 для надежности
— множитель 10 для нестабильности вычислительной машины, применяемой в фазе использования
Все это вместе дает общую оценку в 32,5 доллара за строку. Еще раз повторю, что отдельные факторы должны умножаться на соответствующие коэффициенты, а общая стоимость определяется не перемножением, а суммированием по всем факторам.
Данный пример я рассматривал не ради численных коэффициентов, а лишь как иллюстрацию к методике. Для определения примерных оценок стоимости следует проводить два цикла подобных рассуждений; сначала для максимальных значений множителей по всем факторам, а затем для примерных значений по данной конкретной разработке. Числа, которые использовались в данном примере, выражают также мое мнение об относительной трудности, вносимой каждым отдельным фактором.
В представленном здесь методе игнорируется тот факт, что на самом деле трудность пропорциональна произведению отдельных факторов.
Если бы я применял эту методику в реальной ситуации, мне нужно было бы подсчитывать вклад всех 27 факторов, принимая во внимание те из них, которые, по моему мнению, оказывают наибольшее влияние на конкретное положение дел.
Опыт подсказывает мне, что те, кому удавалось сделать оценки наилучшим образом, проделывали их в обратном порядке. Они оценивали число людей, необходимых для выполнения той или иной функции, и время, необходимое этим людям для выполнения задания, а уже затем определяли, сколько строк в день будут писать эти люди, выводя отсюда полное число строк, необходимое для реализации функции. Я назвал такой порядок обратным. Но, возможно, это и есть прямой путь, а тот метод, который был описан ранее, напротив, является обратным.
Как проводить оценки
Их надо проводить осторожно! Все, что может испортиться, обычно портится. Оценки должны проводиться наиболее квалифицированным специалистом в автоматизируемой области. При необходимости следует привлекать консультантов со стороны. Приглашенные консультанты должны проверять все самые важные оценки. Не следует доверять оценкам тех, кто никогда ранее не участвовал в разработках программ данного типа или объема.
Проведение правильных оценок и правильное проведение оценок. Наши оценки остаются с нами до конца. Но, после того как мы провели их, мы составляем бюджет. А после составления бюджета мы приступаем к разработке. И здесь правильное проведение оценок становится более важным, чем сдача полного набора функций в первый срок. Возможны такие варианты: пересмотр в сторону увеличения стоимостных оценок, задержка выполнения графика работ или уменьшение числа функций с целью удовлетворения первоначальным оценкам. В конце концов, это были всего лишь оценки.
Рис. 6.19. Из чего складывалась общая оценка. 
