Аналитика
Сергей Бобровский
Под качеством программы часто понимается только число найденных в ней ошибок. Однако при реализации серьезных проектов понятие качества необходимо трактовать значительно шире. Помимо количества ошибок оно определяется следующими характеристиками:
- время наработки на отказ;
- устойчивость работы ПО в стрессовых ситуациях и при неверных действиях пользователя;
- степень минимизации использования ресурсов оборудования;
- быстрота обучения пользователя работе с программой;
- адаптируемость к новым требованиям заказчика;
- корректность документации к системе.
***
Компания Price Waterhouse оценивает объем усилий по управлению качеством продуктов в серьезных компаниях - производителях ПО в диапазоне 23 - 34% от общих усилий на разработку. При создании систем с повышенными требованиями к надежности этот объем возрастает до 40 - 55%.
***
При сокращении усилий по тестированию ПО на 20% число ошибок в программе увеличивается на 45%.
***
На этапах проектирования и программирования объем дополнительных пожеланий заказчика возрастает в среднем на 2 - 10% в месяц.
***
В компаниях, которые выполняют проекты в рамках бюджета и в срок, системы управления и контроля качества ПО по функциональным возможностям превосходят аналогичные системы компаний, нарушающих договорные обязательства, в 10 раз, а системы планирования и управления проектами - в 30 раз. Причина успешного выполнения проектов заключается, конечно, не в мощности продуктов, а в наличии менеджеров, умеющих грамотно использовать их в работе.
***
К наиболее типичным причинам провала проектов относятся:
- плохая обратная связь исполнителя с заказчиком;
- неверная оценка бюджета и длительности проекта;
- отсутствие детального плана работ;
- плохой контроль за ходом проекта и отклонениями от запланированных параметров;
- ситуация, когда требования к проекту еще не сформированы до конца, а программисты уже приступили к работе;
- нивелировка требований к менеджерам проектов и техническим сотрудникам;
- неверный выбор архитектуры оборудования (во время войны в Персидском заливе комплекс “Пэтриот” не мог перехватывать новые иракские ракеты, хотя возможности встроенного ПО потенциально позволяли настроить его нужным образом);
- стремление начальников разного уровня делать проект по-своему. Эд Йордон вспоминал, как проект на создание информационной системы стоимостью 300 млн. долл. развалился из-за того, что руководители компании-подрядчика не договорились друг с другом, кто будет ведущим по проекту.
***
Объем проекта часто оценивается по методике подсчета функциональных точек (ф. т., число строк кода, строк документации, пользовательских экранов, таблиц в базе данных и т. д.). Одна ф. т. приблизительно равна 125 операторам Си.
На реализацию проектов размером 1 ф. т. требуется 1 день, и они практически всегда заканчиваются успешно. Это, как правило, создание небольших утилит для временных нужд.
Объем в 10 ф. т. - типичный объем небольших приложений и дополнений, вносимых в готовые системы. Такие проекты требуют до 1 месяца работ и тоже всегда успешны.
Объем в 100 ф. т. близок к пределам возможностей программиста-одиночки. Проект доводится до конца за 6 мес. в 85% случаев. Эти цифры верны для современных средств разработки: 10 лет назад 15 тыс. строк занимал профессиональный интерпретатор Бейсика для ДОС, создать который одному человеку было не под силу (подразумеваются возможности среднего программиста).
Объем проекта в 1000 ф. т. характерен для большинства сегодняшних коммерческих настольных и небольших клиент-серверных приложений. Приличную долю в общем объеме начинает занимать документация. Для разработки необходима группа примерно из 10 программистов, проектировщиков, специалистов по управлению качеством и около года работы. Проваливается 15% подобных групповых проектов и 65% попыток программистов-одиночек. В 20% случаев в срок уложиться не удается. Перерасход средств отмечается в 25% проектов.
Для проекта объемом в 10 000 ф. т. требуется около 100 разработчиков. Остро встают вопросы организации совместной работы нескольких групп сотрудников. Работы длятся от 1,5 до 5 лет, при этом запланированные сроки чаще всего не выдерживаются. Хорошее качество такой системы невозможно обеспечить без использования формальной технологии тестирования. 50% проектов заканчивается неудачей, а реализация такого проекта в одиночку вообще невозможна.
100 000 ф. т. для сегодняшних проектов пока предел. Это объем современных ОС, таких, как Microsoft Windows 95 или IBM MVS, и крупнейших военных систем. На их создание уходит 5 - 8 лет. Над проектом трудятся сотни разработчиков, иногда из разных стран, и эффективно координировать их работу не удается. В законченных системах много ошибок. 65% проектов завершаются провалом. Во всех успешных проектах используются системы конфигурационного управления.
Стоимость такого проекта может равняться стоимости большого стадиона или корабля водоизмещением 70 тыс. тонн.
***
Один из важных факторов, влияющих на стоимость разработки, - ресурсы целевой системы. Можно значительно сократить время и общую стоимость проекта и повысить качество системы, используя компьютеры с большим объемом памяти и высоким быстродействием. Многие алгоритмы удается реализовать значительно проще и эффективнее, если исходить из принципа информационной избыточности, не задумываясь о нехватке оперативной памяти.
Как известно, программ без ошибок не бывает. Но одни ошибки проявляются быстро, а другие порой годами ждут своего часа, чтобы дать о себе знать в самый неподходящий момент. Согласно стоимостным моделям COCOMO и PRICE Systems, если процессор или память загружены не более чем на 50%, ПО работает нормально. Если же загрузка достигает 50 - 90%, эффективность работы программы (скорость выполнения, время отклика) снижается соответственно в 2,3 - 4 раза. При этом возрастает и число проявляющихся ошибок - с 1,8 до 2,9 ошибки на тысячу строк кода.
В крупных проектах по обработке цифровых сигналов (автоматизация промышленных предприятий, магазинов, бортовые комплексы) стоимость ПО в 3 - 4 раза выше стоимости оборудования, а в многопроцессорных системах - в 10 раз. Поэтому экономить на оборудовании невыгодно во всех отношениях. Массачусетский университет совместно с военным научным агентством Darpa провел исследования по выбору оптимального оборудования для беспилотного самолета, способного во время полета обрабатывать информацию от радарной установки. В контрольном варианте использовались шесть системных плат Mercury MCV6 с процессорами Intel I860/40 МГц и 16 Мб DRAM, контроллер Motorola MVME167 и интерфейсная плата для радара. В такой конфигурации нагрузка на память равнялась 86%, нагрузка на процессор - 88%. Стоимость “железа” составила 281 тыс. долл. На разработку ПО потребовалось 32 мес. работы группы программистов из пяти человек и 2 млн. 360 тыс. долл. Когда число плат с процессорами было увеличено с 6 до 11, загрузка процессора и памяти понизилась до 50%. При этом оборудование обошлось в 432 тыс. долл., а расходы на усилия по разработке и отладке ПО согласно стоимостным моделям уменьшились до 911 тыс. долл. Сократилось и время работ - до 28 мес.
***
В год Пентагон тратит в среднем 20 млрд. долл. на неудачные технологические проекты и 60 млрд. долл. на дополнительное финансирование затянувшихся работ. В срок и рамки бюджета укладывается 17% всех проектов. Остальные проекты превышают бюджет на 189%, сроки на 222%, а реализуется в них 61% требуемых заказчиком возможностей.
***
Разработка ПО системы управления огнем для истребителя F-16 обошлась в 85 млн. долл. Объем этого ПО составил 236 тыс. строк кода. Усилия по сопровождению программ комплекса, их улучшению и устранению ошибок потребовали дополнительно 250 млн. долл.
***
Одну из версий Windows NT тестировало 250 инженеров в течение года и выявило 30 тыс. ошибок.
***
48% ошибок OS/370 обнаружено в 4% модулей. В компьютерной системе Агентства национальной безопасности США объемом 25 млн. строк кода 90% всех ошибок встретилось в 13% кода, а 95% серьезных ошибок - в 2,5% кода.
***
Согласно анализу восьми приложений МО США, объемом от 3 до 80 тыс. строк, написанных на Си, Си++, Коболе и Java, одним из главных источников ошибок при внесении изменений в готовые проекты стал плохой учет взаимосвязей между модулями системы, когда вызов функций одного модуля побочно влияет на значения, хранимые в другом модуле. Очень вредят стилю программирования и глобальные переменные, значения которых меняются в разных местах программы, что отследить довольно трудно.
***
Залогом успешной групповой работы над проектом, хороших перспектив его развития и выявления большей части ошибок на ранних стадиях служит максимально подробное документирование исходного текста программы. В крупных военных системах Пентагона на один оператор Ады приходится в среднем 400 слов комментария.
По материалам журнала Journal of Defense Software Engineering и корпорации Cutter
