Сергей Бобровский
PSP 1. Оценка размера будущей программы.
Размер программы, как уже говорилось, удобнее всего оценивать в СК (строках кода). Этот размер складывается из:
- нового кода. Он может быть: а) добавленным к объекту, б) кодом нового объекта и в) измененным кодом старого объекта;
- повторно используемого кода из библиотек;
- базового кода прежней версии.
Однако при подсчете СК необходимо учитывать, что:
- число строк кода (n СК) Паскаля не эквивалентно n СК ассемблера (согласно тестам, максимальное количество ошибок в программе появляется при использовании языков Си, Си++ и Visual Basic, а минимальное - при использовании Паскаля и Ады);
- n новых СК не эквивалентно n модифицированных СК;
- n логических СК не эквивалентно n физических СК;
- и вообще, n СК Си++ не всегда эквивалентно n СК Си++.
Заранее обычно неизвестно, насколько большой будет программа, например, заказчик может выдвинуть дополнительные пожелания. Бывает и так, что оценка размера меняется под давлением руководства. Поэтому в протоколах работы наряду с СК надо стараться фиксировать другие характеристики (сложность задачи, требования к ресурсам и т. д.) и пытаться определить их влияние на размер программы. Способность правильно оценить этот размер приходит с опытом и становится настоящим критерием мастерства программиста.
При использовании объектно-ориентированных технологий значительно эффективнее оценивать размер программы не в СК, а в объектах, которые помимо своего размера в СК дополнительно характеризуются числом методов, размером каждого метода в СК и типом (хранилище данных, вычисления, ввод-вывод, управляющий объект, реализация логики, инициализация данных, переменных и т. д.). Наиболее высокую корреляцию с размером программы показал критерий “общий размер объекта в СК/число методов данного объекта”.
PSP 1.1. Оценка рабочего времени, составление календарного плана (КП).
При прогнозе объемов работ на основании накопленного опыта программист начинает использовать методы статистической оценки. Исследования показали, что зависимость между размером программы и временем ее создания линейная, поэтому достаточно подобрать два коэффициента регрессии.
Лучшей стратегией составления хорошего КП в PSP считается максимально возможная детализация всех работ в рамках проекта. Для этого надо учиться выявлять отдельные подзадачи, которые программист способен оценить достаточно точно.
КП составляется следующим образом.
1. Определяются требования к продукту и основные модули, реализующие логику программы. Оценивается размер этих модулей в СК. Без данного этапа оценить размер всей программы практически невозможно, так как будет непонятна ее внутренняя структура.
2. Объем работ в СК переводится в рабочие часы и определяется время на создание каждого модуля. На основе этих оценок и календаря составляется график работ.
В дальнейшем программист должен периодически составлять отчеты о проделанной работе. Это необходимо для анализа персонального процесса разработки (ППР) и контроля за отклонением фактически затраченного на отдельные подзадачи времени от запланированного. Если это отклонение становится существенным (на план влияют непредвиденные события, неожиданные сложности и возникающие ошибки) или понадобилось внести в план новые работы, то необходимо переписать весь план заново - PSP не допускает его корректировки, потому что, как показывает статистика, было выяснено, что процесс корректировки плана значительно сложнее планирования с нуля и обычно служит источником новых ошибок. По реально затрачиваемому на первые этапы времени можно затем точнее прогнозировать время завершения всего проекта.
PSP 2. Управление качеством.
К критериям измерения работы добавляется новый - число ошибок. Программист учится выявлять дефекты в своих программах. Для этого применяется методика обзоров кода (code reviews) и проекта программы в сочетании с технологией иерархического проектирования ПО. Число ошибок прогнозируется по этапам плана. На каждом этапе фиксируется размер просмотренного кода, затраченное на просмотр время и число найденных ошибок.
В КП дополнительно включаются новые этапы по устранению дефектов - своеобразные фильтры ошибок. По окончании проекта анализируется, на каких этапах произошло отклонение числа ошибок от запланированных величин и в чем причина этого расхождения. Если программист внимательно просмотрит свой отчет по обнаруженным ошибкам, он сможет определить их главные источники и попытаться найти наиболее эффективные способы снижения их числа.
Основная методика, предлагаемая PSP для выявления ошибок, - обзор кода, интуитивно названный отечественными программистами “методом пристального взгляда”. Цель обзора - найти как можно больше ошибок в новом коде перед его первой компиляцией. Компилятор не рекомендуется применять даже для выявления синтаксических ошибок, как ни удивительно это покажется подавляющему большинству программистов! Это самый принципиальный элемент PSP. Дело в том, что, согласно статистике, компилятор языка Си++ не замечает 9,4% синтаксических ошибок, и не только опечатки (вместо оператора цикла for набрано foe, что можно обнаружить на основе анализа контекста автоматически). Например, вместо индекса i используется j. И та, и другая переменные описаны в программе, поэтому такая ошибка компилятором не распознается, а на этапе тестирования время на устранение подобных ошибок увеличивается в десятки раз.
Обзор кода - это визуальный просмотр текста программы, анализ логики выполнения отдельных операторов и другие методы проверки и поиска ошибок, формализованные инструкциями PSP. Например: проверка всех параметров модулей на выход за границы допустимых значений, проверка циклов и рекурсий на нормальное и ненормальное завершение, анализ взаимосвязей объектов и т. д. Обычно такие проверки реализуются программно, но гораздо важнее и эффективнее попытаться это сделать, не прибегая к тестированию, чтобы сразу выявить первопричины возможной некорректной работы.
По данным разных исследований, при обзоре кода одна ошибка выявляется и ликвидируется в среднем каждые 5 - 20 мин (на этапе тестирования модулей - каждые 15 - 30 мин) и на этапе комплексного тестирования - каждые 8 ч. При этом число ошибок, устраняемых на этапе компиляции, снижается с 76 на одну тысячу СК до 13, а выявляемых при тестировании - с 34 до 10.
Устранение ошибок на ранних этапах положительно сказывается и на психологическом состоянии программиста. Он чувствует себя значительно увереннее, если код компилируется с первого раза и модули начинают правильно работать. Немаловажна здесь высокая корреляция (0,711) между числом ошибок, найденных на этапе компиляции и этапе тестирования, т. е. если код исходно пишется неаккуратно и невнимательно, то компилятор не сможет выявить все огрехи и, как следствие, много ошибок будет и в готовом продукте.
Тестирование имеет немало недостатков, так как на этом этапе ищутся ошибки в неизвестных местах программы, и когда в продукте находится дефект, его надо локализовать, ликвидировать и протестировать продукт заново. А при обзорах кода ошибка сразу видна непосредственно в тексте, понятна логика ее исправления и сам процесс устранения проходит быстро.
Какое-то число ошибок в программе останется. Но готовый продукт должен корректно обрабатывать любые ненормальные ситуации, а возникающие ошибки не должны приводить к краху системы и, конечно, желательно, чтобы они встречались как можно реже.
PSP 2.1. Проектирование программы.
Сначала составляются требования к проекту - определяется, что пользователю надо. Затем создается спецификация проекта - формальные требования к программе (что программа должна делать). Потом выполняется высокоуровневое проектирование будущего продукта, т. е. определяется, как программа работает. На заключительном этапе составляются спецификации отдельных модулей.
Процесс непосредственной разработки программы также организован иерархично. На верхнем уровне формулируются требования к модулю (что модулю надо от других частей программы), затем создается спецификация модуля (что модуль делает), осуществляется его детальное проектирование (как модуль работает) и только на последнем этапе пишется исходный код.
PSP 3. Совершенствование ППР.
Программист учится анализировать эффективность ППР и качество проектов, точно оценивать убытки от ошибок, совершенствует различные способы их выявления, устранения и предупреждения.
Циклическая разработка программ в PSP выглядит так:
- определяются цели ППР;
- определяются методы для достижения этих целей;
- вся работа измеряется;
- вся работа анализируется;
- на основе анализа проекта эти методы улучшаются.
Используя стандартные формы, сценарии, отчеты, программист тщательно исследует протоколы своей работы для улучшения ППР. При анализе отчетов в первую очередь выявляются типы наиболее часто встречающихся и наиболее опасных ошибок. При этом фиксируются тенденции снижения их числа в зависимости от используемых методов профилактики. Оценивается стоимость качества, определяется и отслеживается эффективность различных методов обзора кода и проекта, подбираются все более оптимальные способы оценки разных сторон ППР.
Заключение
Если программисты компании обучены PSP, принципиально меняются задачи менеджеров, которые сегодня подбираются в основном по способности организовать авральную работу сотрудников по ночам. Такие руководители проектов могут работать только дремучим способом латания дыр “раздал задание - получил от программистов код - протестировал получившуюся версию продукта - нашел кучу ошибок - вернул обратно на доработку”. Однако современные технологии программной инженерии требуют от менеджеров проектов совсем другого - вместо примитивного контроля за календарными планами они должны контролировать качество продукта и управлять этим качеством. Чем меньше будет в программе ошибок, тем быстрее появится на рынке хороший продукт. Поэтому лучшей характеристикой программиста сегодня должны стать не просто знание Си++ и SQL, а способность планировать свой труд, разрабатывать программу точно в срок и, самое главное, без ошибок.
О PSP можно почитать на Web-узле: www. sei.cmu.edu.
Окончание. Начало см. PC Week/RE, № 20/98, с. 47.
