Критерии качества програмного обеспечения

      Приведенные выше ответы показывают, что качество ПО может быть описано большим  набором разнородных характеристик. Такой подход к описанию сложных понятий называется холистическим (от греческого слова όλος, целое). Он не дает единой концептуальной основы для рассмотрения затрагиваемых вопросов, какую дает целостная система представлений (например, механика Ньютона в физике или классическая теория вычислимости на основе машин Тьюринга), но позволяет, по крайней мере, не упустить ничего существенного.

Что делает программу высококачественной:

      Шломи Фиш (Shlomi Fish) проанализировал факторы определяющие высокое качество программного обеспечения:

• Программа должна часто обновляться и быть всегда доступна для скачивания или покупки.
• Должно быть легко узнать номер версии. Лучше если номер версии можно узнать без установки и запуска из пути для скачивания и из имени архива или из имени папки установки.
• Код программы должен быть открытым, лучше если лицензия позволяет свободное использование кода.
• Программа не должна требовать существенной настройки или дополнительного обучения (изменения привычек).
• Программа должна иметь качественную веб-страницу, где легко найти всю необходимую информацию.
• Программа не должна быть сложной в компиляции и запуске, не должна использовать особенности компиляторов и должна иметь немного зависимостей.
• Должны быть легко доступны готовые собранные пакеты или должно быть легко их собрать.
• Программа должна быть хорошо документирована.
• Программа должна быть переносимой (работать на как можно большем количестве распространенных платформ).
• Высококачественная программа должна быть безопасна - это означает что должно быть немного проблем с безопасностью и баги должны исправляться быстро.
• При выходе новых версий должна сохраняться совместимость со старыми.
• Высококачественная программа имеет хорошие пути поддержки пользователей - почтовые рассылки, IRC, техподдержку по email, форумы, wiki.
• Программа должна быть быстрой и не должна потреблять много ресурсов.
• И конечно же высококачественная программа должна быть эстетичной и не перегружать пользователя излишней информацией.

Как сделать программу высококачественной?

• Код программы должен быть модульным и хорошо написанным.
• В разработке должны использоваться автоматические тесты, лучше если тест пишется до начала написания тестируемого кода.
• Нужно иметь хороший контакт с сообществом пользователей, которые будут тестировать бета-версии и предлагать улучшения.
• Релизы должны быть частыми.
• Управление проектом должно быть объективным и дальновидным.
• Слишком навязчивая реклама вредна, и совершенно недопустима неправдивая реклама.
• И последнее: хорошее название программы важно.

Качество  ПО по МакКолу

      Первой  широко известной моделью качества ПО стала предложенная в 1977 МакКолом.

      В ней характеристики качества разделены  на три группы

• Факторы (factors), описывающие ПО с позиций пользователя и задаваемые требованиями.
• Критерии (criteria), описывающие ПО с позиций разработчика и задаваемые как цели.
• Метрики (metrics), используемые для количественного описания и измерения качества.

      Факторы качества, которых было выделено 11, группируются в три группы по различным способам работы людей с ПО. Полученная структура изображается в виде треугольника МакКола.

Рис. 9. Треугольник МакКола.

      Критерии  качества - это числовые уровни факторов, поставленные в качестве целей при разработке.

      Объективно  оценить или измерить факторы  качества непосредственно довольно трудно. Поэтому, МакКол ввел метрики качества, которые с его точки зрения легче измерять и оценивать. Оценки в его шкале принимают значения от 0 до 10. Вот эти метрики качества:

• Удобство проверки на соответствие стандартам (auditability)
• Точность управления и вычислений (accuracy)
• Степень стандартности интерфейсов (communication commonality)
• Функциональная полнота (completeness)
• Однородность используемых правил проектирования и документации (consistency)
• Степень стандартности форматов данных (data commonality)
• Устойчивость к ошибкам (error tolerance)
• Эффективность работы (execution efficiency)
• Расширяемость (expandability)
• Широта области потенциального использования (generality)
• Независимость от аппаратной платформы (hardware independence)
• Полнота протоколирования ошибок и других событий (instrumentation)
• Модульность (modularity)
• Удобство работы (operability)
• Защищенность (security)
• Самодокументированность (selfdocumentation)
• Простота работы (simplicity)
• Независимость от программной платформы (software system independence)
• Возможность соотнесения проекта с требованиями (traceability)
• Удобство обучения (training)

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

Качество  ПО по Боему 

      В 1978 Боем предложил свою модель, по существу представляющую собой расширение модели МакКола.

      Атрибуты  качества подразделяются по способу  использования ПО (primary use).

      Определено 19 промежуточных атрибутов (intermediate construct), включающих все 11 факторов качества по МакКолу. Промежуточные атрибуты разделяются на примитивные (primitive construct), которые, в свою очередь, могут быть оценены на основе метрик.

      В дополнение к факторам МакКола атрибуты качества по Боему включают следующие: ясность (clarity), удобство внесения изменений (modifiability), документированность (documentation), способность к восстановлению функций (resilience), понятность (understandability), адекватность (validity), функциональность (functionality), универсальность (generality), экономическая эффективность (economy). [13] 

1.5 Оценка результата

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

1.5.1 Линейный подход

     В простейшем случае определить стоимость разработки ПО можно исходя из количественной оценки трудозатрат Т (в неких единицах, например человеко-месяцах или человеко-часах) и их удельной стоимости Ц:

          С = Т × Ц.

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

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

          Т = Р × П,

где Р  - размер исходного кода ПО; П - временная производительность.

     Эта примитивная формула активно  применяется и по сей день, хотя ее несостоятельность была установлена  довольно давно. Пожалуй, самой известной  работой, в которой критикуется  данный подход, является выдержавшая более двадцати изданий по-настоящему классическая книга Фредерика Брукса (Frederick Brooks) «Мифический человеко-месяц, или Как создаются программные системы», впервые увидевшая свет еще в 1977 г.

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

      С ростом мастерства программист обычно делается «лаконичнее», т. е. выдаваемый им код для решения одних и тех же задач становится все компактнее, а это означает, что его проще и дешевле отлаживать и сопровождать. Однако вышеуказанная формула вовсе не стимулирует данного процесса. 

1.5.2 Оценка с использованием эмпирических данных

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

SLIM. Вернемся к нашей линейной формуле определения трудозатрат - как мы уже говорили, она была признана несостоятельной, но если ранее мы сомневались только в способе исчисления размера ПО, то теперь задумаемся о ее линейном характере.

     О том, что трудоемкость и, соответственно, стоимость программного проекта нелинейно зависит от объема работ, было известно еще в 1970-х годах, когда появились первые научные публикации, подкрепленные результатами серьезных исследований.

     Вероятно, первой нелинейной моделью, использующей эмпирические данные и нашедшей практическое применение при оценке стоимости ПО, стала SLIM (Software Life-cycle Model), предложенная в 1978 г. Лоуренсом Патнамом (Lawrence Putnam). Согласно ей трудоемкость вычисляется по следующей формуле:

     Размер  проекта (P) чаще всего исчисляется  в количестве строк кода, хотя известны случаи успешного применения модели и для других единиц, например функциональных точек. C - фактор среды, некая технологическая константа, учитывающая, помимо уровня технологий, также и производительность персонала, которая может различаться от команд к команде. t_d - ограничение на срок поставки (в годах).

     SLIM была создана на базе реальных  данных, собранных в Министерстве  обороны США, и ориентирована  в первую очередь на крупные проекты. Несмотря на возможность калибровки модели на основе хронологической информации, что несколько повышает качество результатов, она не приобрела широкой популярности, хотя существуют организации, успешно использующие ее в проектном менеджменте и сегодня (qsm.com).

     COCOMO. Пожалуй, самой популярной моделью для оценки стоимости разработки ПО, которая стала стандартом, является COCOMO (COnstructive COst MOdel). Она была представлена в 1981 г. Барри Боэмом (Barry Boehm), известным ученым, внесшим огромный вклад в развитие научных подходов к управлению программными проектами - им разработаны спиральная модель проектирования ПО и Wideband Delphi, кроме того, когда-то именно он предсказал, что в будущем стоимость ПО превысит стоимость оборудования.

     COCOMO создана на основе анализа  статистических данных 63 проектов  различных типов. Фактически под  общим названием скрываются три  уровня детализации: базовый,  промежуточный и подробный. Также  предусмотрено три режима использования  модели в зависимости от размеров команды и проекта (табл. 1). 

Режимы  модели COCOMO

Таблица 3.