Критерии качества програмного обеспечения (стр. 11 из 17)
По мнению Брукса, «...наши методы оценки ошибочно путают достигнутый прогресс с затраченными усилиями...». В первую очередь, это утверждение касается способа, которым измеряется результат, - на заре программирования не было найдено ничего лучшего, чем использование в этих целях количества строк кода. Об абсурдности такого показателя для оценки программного проекта сказано очень много, что, впрочем, вовсе не означает, что он не применяется сегодня.
С ростом мастерства программист обычно делается «лаконичнее», т. е. выдаваемый им код для решения одних и тех же задач становится все компактнее, а это означает, что его проще и дешевле отлаживать и сопровождать. Однако вышеуказанная формула вовсе не стимулирует данного процесса.
1.5.2 Оценка с использованием эмпирических данных
Несмотря на определенные достижения рассмотренных методов при оценке трудоемкости реализации программных проектов, опытный менеджер скажет, что лучший способ узнать длину пути - это пройти его. Действительно, ничто не вселяет в нас больше уверенности, чем прошлый опыт.
SLIM. Вернемся к нашей линейной формуле определения трудозатрат - как мы уже говорили, она была признана несостоятельной, но если ранее мы сомневались только в способе исчисления размера ПО, то теперь задумаемся о ее линейном характере.
О том, что трудоемкость и, соответственно, стоимость программного проекта нелинейно зависит от объема работ, было известно еще в 1970-х годах, когда появились первые научные публикации, подкрепленные результатами серьезных исследований.
Вероятно, первой нелинейной моделью, использующей эмпирические данные и нашедшей практическое применение при оценке стоимости ПО, стала SLIM (Software Life-cycle Model), предложенная в 1978 г. Лоуренсом Патнамом (Lawrence Putnam). Согласно ей трудоемкость вычисляется по следующей формуле:
Размер проекта (P) чаще всего исчисляется в количестве строк кода, хотя известны случаи успешного применения модели и для других единиц, например функциональных точек. C - фактор среды, некая технологическая константа, учитывающая, помимо уровня технологий, также и производительность персонала, которая может различаться от команд к команде. td - ограничение на срок поставки (в годах).
SLIM была создана на базе реальных данных, собранных в Министерстве обороны США, и ориентирована в первую очередь на крупные проекты. Несмотря на возможность калибровки модели на основе хронологической информации, что несколько повышает качество результатов, она не приобрела широкой популярности, хотя существуют организации, успешно использующие ее в проектном менеджменте и сегодня (qsm.com).
COCOMO. Пожалуй, самой популярной моделью для оценки стоимости разработки ПО, которая стала стандартом, является COCOMO (COnstructive COst MOdel). Она была представлена в 1981 г. Барри Боэмом (Barry Boehm), известным ученым, внесшим огромный вклад в развитие научных подходов к управлению программными проектами - им разработаны спиральная модель проектирования ПО и Wideband Delphi, кроме того, когда-то именно он предсказал, что в будущем стоимость ПО превысит стоимость оборудования.
COCOMO создана на основе анализа статистических данных 63 проектов различных типов. Фактически под общим названием скрываются три уровня детализации: базовый, промежуточный и подробный. Также предусмотрено три режима использования модели в зависимости от размеров команды и проекта (табл. 1).
Режимы модели COCOMO
Таблица 3.
| Название режима | Размер проекта | Описание |
| Органичный | До 50 KLOC | Некрупный проект разрабатывается небольшой командой, для которой нехарактерны нововведения, и среда остается стабильной |
| Сблокированный | 50 - 300 KLOC | Относительно небольшая команда занимается проектом среднего размера, в процессе разработки необходимы определенные инновации, среда характеризуется незначительной нестабильностью |
| Внедренный | Более 300 KLOC | Большая команда разработчиков трудится над крупным проектом, необходим значительный объем инноваций, среда состоит из множества элементов, которые не характеризуются стабильностью |
Для оценки трудозатрат на базовом уровне модели COCOMO применяется следующая формула:
Т = a × Р b,
где a и b - константы, которые зависят от режима использования модели.
В соответствии с этой формулой трудозатраты вообще нелинейно зависят от размера проекта и скачкообразно изменяются при смене режима (табл. 2). Другая интересная особенность COCOMO - рост трудозатрат при переходе к более высокому режиму не означает безусловного увеличения длительности (F) выполнения проекта, которая вычисляется по формуле:
F = 2,5 × Т k,
поскольку при этом изменяется значение константы k.
Значения коэффициентов модели COCOMO в зависимости от режима использования
Таблица 4
| Название режима | Значение коэффициента a | Значение коэффициента b | Значение коэффициента k |
| Органичный | 2,4 | 1,05 | 0,38 |
| Сблокированный | 3,0 | 1,12 | 0,35 |
| Внедренный | 3,6 | 1,20 | 0,32 |
На более высоких уровнях COCOMO рассмотренные формулы усложняются, они обрастают дополнительными коэффициентами, позволяющими повысить точность оценок. Также модель допускает калибровку на основе хронологических данных по выполненным проектам.
COCOMO II. Сегодня оригинальная COCOMO уже считается устаревшей. Ей на смену пришла COCOMO II, представленная в 1997 г. Хотя она и имеет много общего со своей предшественницей, однако во многом основана на новых идеях, а также адаптирована к современным методологиям разработки ПО (в частности, если COCOMO подразумевала только каскадную модель жизненного цикла, то COCOMO II также пригодна для спиральной и итеративной).
При построении COCOMO II для обработки статистических данных использовался Байесовский анализ, который дает лучшие результаты для программных проектов, характеризующихся неполнотой и неоднозначностью, в отличие от многофакторного регрессионного, примененного в COCOMO. Также в ней допускается измерять размер проекта не только числом строк кода, но и более современными функциональными и объектными точками. Помимо прочего, при расчете показателей COCOMO II учитывает уровень зрелости процесса разработки в соответствии с моделями SEI CMM/CMMI.
Как и COCOMO, COCOMO II также имеет несколько вариантов использования, однако они отличаются не столько детализацией, сколько характером - фактически это разные модели для решения разных (хотя и схожих) задач, объединенные под одним общим названием. При этом формулы для вычисления различных показателей значительно усложнились. При сохранении основных принципов модель стала намного гибче и учитывает гораздо большее число факторов, влияющих на выполнение программного проекта. [15]
Модель COCOMO II фактически объединяет три различные подмодели
Таблица 5
| Название модели | Описание |
| Композиционная прикладная | Ориентирована на проекты, создаваемые с применением современных инструментальных средств и UML, использует в качестве метрики объектные точки |
| Ранней разработки проекта | Применяется для получения приближенных оценок по проекту до определения его архитектуры, использует в качестве метрик количество строк кода или функциональные точки |
| Постархитектурная модель | Наиболее детализированная модель, используется после разработки архитектуры проекта и позволяет получить самые точные оценки, применяет в качестве метрик количество строк кода или функциональные точки |
Как контролировать качество системы? Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании? Ответы на эти вопросы можно получить с помощью процессов верификации и валидации.
· Верификация обозначает проверку того, что ПО разработано в соответствии со всеми требованиями к нему, или что результаты очередного этапа разработки соответствуют ограничениям, сформулированным на предшествующих этапах.
· Валидация - это проверка того, что сам продукт правилен, т.е. подтверждение того, что он действительно удовлетворяет потребностям и ожиданиям пользователей, заказчиков и других заинтересованных сторон.
Эффективность верификации и валидации, как и эффективность разработки ПО в целом, зависит от полноты и корректности формулировки требований к программному продукту.
Основой любой системы обеспечения качества являются методы его обеспечения и контроля. Методы обеспечения качества представляют собой техники, гарантирующие достижение определенных показателей качества при их применении. Мы будем рассматривать подобные методы на протяжении всего курса.
Методы контроля качества позволяют убедиться, что определенные характеристики качества ПО достигнуты. Сами по себе они не могут помочь их достижению, они лишь помогают определить, удалось ли получить в результате то, что хотелось, или нет, а также найти ошибки, дефекты и отклонения от требований. Методы контроля качества ПО можно классифицировать следующим образом: