Программное обеспечение и его разработка - [97]

Форма отчетности по строкам программ

Желательно, чтобы отчеты по проектам выглядели как-нибудь так:

Название: Программа наведения ракет: с математическим уклоном; загружается с перекрытием; критическая по времени.

Функции: Расчет курса, скорости и всех управляющих сигналов, необходимых для ведения ракеты к точке перехвата другой ракеты.

Не включено в программу:		а) Отслеживание всех ракет; делается другой программой.
		б) Прием и передача всех сигналов; делается где-то в другом месте.
Всего выполняемых стп —		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

Оценка

Оценка размеров программы

Если бы нам заранее были известны размеры программ, которые нам предстоит написать, наше положение было бы намного лучше уже с самого начала разработки большого проекта.

Предложив опытному разработчику изучить уже работающие системы, мы могли бы получить хорошие оценки числа строк программы для тех работ, которым можно найти аналоги среди ранее запрограммированных.

Здесь мы со всей очевидностью сталкиваемся с неким порочным кругом: «Вам нельзя доверить работу, у вас нет опыта». «Как же я могу получить опыт, если мне не дают работать?» Наше положение именно таково. Мы хотим, чтобы оценки делались кем-то, кто уже делал это в прошлом. Или делал что-то, похожее на то, что мы пытаемся сделать.

Теперь нам очень пригодятся наши знания о пяти типах использования вычислительных машин и таксономии программного обеспечения. То, что человек имеет опыт разработки крупных прикладных систем, не означает, что он сможет оценить усилия, необходимые для создания системного программного обеспечения. Эта ситуация должна служить вам в качестве предупреждения. Не надо слушать прикладников, пытающихся оценивать трудности системного обеспечения! Не позволяйте людям, разрабатывавшим пакетные программы, оценивать системы реального времени. Это же относится и ко всем другим категориям.

Факторы, определяющие трудность разработки

На усложнение или облегчение разработки влияет сразу целая комбинация факторов. Прежде, чем закончить главу я хочу перечислить 27 из них. Все они разбиваются на три основные категории:

(A) Функция, которую надо выполнить

(B) Окружение в фазе использования

(C) Факторы, действующие в фазе разработки

Трудность разработки программ = (А) × (В) × (С)

Таблица 6.2. Трудности разработки

	Тип использования
	I	II	III	IV	V
Функциональные
Функции, которые надо реализовать, количество					+
Функции, которые надо реализовать, сложность		+			+
Функции, которые надо реализовать, ясность					+
Взаимодействие людей с системой			+	+	++
Число различных пользователей системы			+	+	+
Число запусков программы			+	+	+
Число машин, на которых будет выполняться система					+
Функции, которые надо реализовать, взаимодействия					+
Элементы данных
Ожидаемая частота внесения изменений в систему			+
Взаимодействия с другими системами					+
Окружение фазы использования
Центральный процессор	-	+		+	+ +
Ввод/вывод	+	-			+
Основная память	-				+
Вспомогательная память			+
Надежность/доступность			+	+	+ +
Реальное время					+ +
Факторы фазы разработки
Адекватность операционной системы			+	+	+ +
Время, выделенное на создание программного обеспечения					+
Доступность средств разработки; языки, отладчики и т. д.