Программное обеспечение и его разработка
Шрифт:
До тех пор, пока этого не сделано, идея использования «баз данных» истории проектов для предсказания денежных и других затрат остается совершенно наивной. Она совершенно бессмысленна; воздействующих факторов слишком много.
Множество чисел, интерпретируемых как чисто случайные.
Рис. 6.18 заимствован из исследования Правительства США, посвященного изучению соотношения числа строк сдаваемой исходной программы (ЧССИП) и производительности (СТП/ЧМ). Заметьте, что по обеим осям разметка нанесена в логарифмическом масштабе. Единственное, что показывают эти данные, это, что никаких полезных оценок на их основании сделать нельзя. Разнообразие их просто поразительно.
Рисунок полезен только тем, что показывает отсутствие у нас достаточного
Предупреждение. Использовать строки программ как меру производительности труда и метод оценки в настоящее время просто абсурдно. Неизвестно, каким образом можно сопоставлять реализуемую функцию и строки программы. Если руководство настаивает на повышении скорости создания строк программы, программист всегда может написать «рыхлую», «пухлую» программу, которая сделает хорошими все показатели по производительности труда, но которая абсолютно не подходит для настоящего дела, так как для выполнения такой программы может понадобиться слишком много памяти и процессорного времени. Мне встречалось много таких «хороших» руководителей, требующих от каждого программиста как можно больше строк программ в месяц.
Желательно, чтобы отчеты по проектам выглядели как-нибудь так:
Название: Программа наведения ракет: с математическим уклоном; загружается с перекрытием; критическая по времени.
Функции: Расчет курса, скорости и всех управляющих сигналов, необходимых для ведения ракеты к точке перехвата другой ракеты.
| Не включено в программу: | а) Отслеживание всех ракет; делается другой программой. | |
| б) Прием и передача всех сигналов; делается где-то в другом месте. | ||
| Всего выполняемых стп — | 36 441 | |
| в рабочей программе | ||
| Написано СТП (выполняемых) ЯВУ | 7014 | |
| машинный язык | 1314 | |
| Не написано, но выполняется | 8424 | |
| Человеко-месяцев (прямой подсчет) | 340 человеко-месяцев | |
| Программы [38] , написанные, но не сохраненные (выброшенные) | 26 584 | |
| 8144 Тесты | ||
| 11 240 имитаторы | ||
| 3100 моделирование | ||
| 4100 проч. | ||
| Программы [39] , написанные и оставленные, но не выполняемые | 50 445 всего | |
| 22 814 тестовые программы последней версии | ||
| 18 416 примечания | ||
| 1114 моделирование | ||
| 8101 варианты данных | ||
| Время от начала работы до сдачи | 18 месяцев | |
| Время первой итерации | Составления спецификации требований | 4 месяца |
| Составления проектной документации | 8 месяцев |
Этот пример приведен здесь для иллюстрации некоторых принципов, изложенных на предыдущих страницах. Некоторых, но отнюдь не всех. В полную отчетную форму необходимо включать подробные ответы на многочисленные вопросы, в которых, как мы уже установили, мы нуждаемся — какой тип вычислительной машины использовался для трансляции и т. п.
В результате всех этих усилий мы пришли к тому, что никто не способен предсказывать производительность труда для выбранного случайным образом большого программного проекта. Слишком уж много параметров, слишком много качественных факторов, оказывающих значительное воздействие на исход дела. Мы можем оказаться недалеко от истины только для некоторых работ, которые ведутся проверенной группой в хорошо известной прикладной области.
Ниже приводятся некоторые промежуточные результаты замеров, проводившихся в IBM над программными проектами. Работы сгруппированы на основе предсказаний их руководителей по степени трудности. Посмотрите, какие наблюдаются грандиозные различия в производительности труда, измеренной в строках текста программ (СТП) в месяц.
| Достигнутая производительность труда | |
|---|---|
| Маленький/легкий [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 |
40
Производительность труда, предсказанная руководством проекта.
Если бы нам заранее были известны размеры программ, которые нам предстоит написать, наше положение было бы намного лучше уже с самого начала разработки большого проекта.
Предложив опытному разработчику изучить уже работающие системы, мы могли бы получить хорошие оценки числа строк программы для тех работ, которым можно найти аналоги среди ранее запрограммированных.
Здесь мы со всей очевидностью сталкиваемся с неким порочным кругом: «Вам нельзя доверить работу, у вас нет опыта». «Как же я могу получить опыт, если мне не дают работать?» Наше положение именно таково. Мы хотим, чтобы оценки делались кем-то, кто уже делал это в прошлом. Или делал что-то, похожее на то, что мы пытаемся сделать.
Теперь нам очень пригодятся наши знания о пяти типах использования вычислительных машин и таксономии программного обеспечения. То, что человек имеет опыт разработки крупных прикладных систем, не означает, что он сможет оценить усилия, необходимые для создания системного программного обеспечения. Эта ситуация должна служить вам в качестве предупреждения. Не надо слушать прикладников, пытающихся оценивать трудности системного обеспечения! Не позволяйте людям, разрабатывавшим пакетные программы, оценивать системы реального времени. Это же относится и ко всем другим категориям.
На усложнение или облегчение разработки влияет сразу целая комбинация факторов. Прежде, чем закончить главу я хочу перечислить 27 из них. Все они разбиваются на три основные категории:
(A) Функция, которую надо выполнить
(B) Окружение в фазе использования
(C) Факторы, действующие в фазе разработки
Трудность разработки программ = (А) x (В) x (С)
Таблица 6.2. Трудности разработки