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

— документирования

— стандартизации методов кодирования

Не использовались ли необычные устройства ввода/вывода или средства отображения? Не было ли это оборудование использовано каким-либо необычным образом? Работала ли программистская группа на данной машине прежде? На этом же языке? С приложениями таких же размеров и сложности? Работали ли ведущие программисты прежде того в совместных проектах? Каково было окружение разработки? Работа велась с выделением пультового времени? Или в режиме разделения времени? Использовались ли удаленные терминалы? Привлекались ли программисты к непосредственной работе на машине? Каким было время ожидания решения? Применялся ли диалоговый режим? Как долго? Менее 2 ч, от 2 до 7 ч, от 8 до 24 ч, более 24 ч? Какая доля программ разрабатывалась с использованием:

— библиотеки инструментальных программ,

— программного библиотекаря,

— структурного программирования,

— сквозного контроля,

— программирования сверху вниз,

— метода главного программиста?

После этого мы приступили к оценкам сложности:

— приложений,

— алгоритма программ,

— межпрограммных связей,

— внешних связей,

— структуры базы данных.

Какая доля программ пришлась на:

— нематематические приложения и форматирование ввода/вывода,

— математические и вычислительные программы,

— программы управления центральным процессором и вводом/выводом,

— программы возвратов и восстановления после сбоев?

Какие ограничения повлияли на проект:

— в оперативной памяти,

— временные,

— возможностей ввода/вывода?

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

— управлении,

— администрации,

— программировании,

— анализе,

— технических работах.

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

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

Ошибки при подсчете СТП

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

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

Большой ошибкой является подсчет числа СТП за человеко-месяц уже в середине разработки. Если вы оценили полное число строк программы и среднее число строк за человеко-месяц и «заключили соглашение» на выполнение работ, вы должны постараться не впасть в ошибку «измерений в середине». Не следует считать уровень производительности труда, достигнутый на каком-то этапе, постоянным и использовать его для расчета производительности труда на последующих этапах.

Как-то у нас был контракт на западном берегу, в котором мы недооценили объем программ примерно вдвое. Мы сменили руководителя — и новый не хотел отвечать за чужие грехи. Спорить с этим было трудно.

Этот новый руководитель утверждал, что наши цифры по производительности труда также были неверными. Он взял производительность в момент времени х (см. рис. 6.17) и заявил, что он попытается достигнуть именно такой же производительности для всего проекта в целом.

Рис. 6.17. Изменения отношения строк текста программы к человеко-месяцам во время работы над программным обеспечением для проекта