Критерии качества програмного обеспечения (стр. 10 из 17)
Fi = SIGN (Nкомм. i / Ni - 0,1)
Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется Fi [5]
1.4 Альтернативные подходы к измерению качества
Как проверить, что требования определены достаточно полно и описывают все, что ожидается от будущей программной системы? Это можно сделать, проследив, все ли необходимые аспекты качества ПО отражены в них. Именно понятие качественного ПО соответствует представлению о том, что программа достаточно успешно справляется со всеми возложенными на нее задачами и не приносит проблем ни конечным пользователям, ни их начальству, ни службе поддержки, ни специалистам по продажам. Да и самим разработчикам создание качественной программы приносит гораздо больше удовольствия.
Если попросить группу людей высказать свое мнение по поводу того, что такое качественное ПО, можно получить следующие варианты ответов:
· Легко использовать.
· Хорошая производительность.
· Нет ошибок.
· Не портит пользовательские данные при сбоях.
· Можно использовать на разных платформах.
· Может работать 24 часа в сутки и 7 дней в неделю.
· Легко добавлять новые возможности.
· Удовлетворяет потребности пользователей.
· Хорошо документировано.
Все это действительно имеет непосредственное отношение к качеству ПО. Но эти ответы выделяют характеристики, важные для конкретного пользователя, разработчика или группы таких лиц. Для того чтобы удовлетворить потребности всех сторон (конечных пользователей, заказчиков, разработчиков, администраторов систем, в которых оно будет работать, регулирующих организаций и пр.), для достижения прочного положения разрабатываемого ПО на рынке и повышения потенциала его развития необходим учет всей совокупности характеристик ПО, важных для всех заинтересованных лиц.
Приведенные выше ответы показывают, что качество ПО может быть описано большим набором разнородных характеристик. Такой подход к описанию сложных понятий называется холистическим (от греческого слова όλος, целое). Он не дает единой концептуальной основы для рассмотрения затрагиваемых вопросов, какую дает целостная система представлений (например, механика Ньютона в физике или классическая теория вычислимости на основе машин Тьюринга), но позволяет, по крайней мере, не упустить ничего существенного.
Что делает программу высококачественной:
Шломи Фиш (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]
Оценка результата программных проектов - задача весьма сложная. Зачастую какие-то показатели нужны еще до начала работ, чтобы спланировать будущие расходы, другие используются для определения размера вознаграждения за уже выполненный труд. Наука не стоит на месте и предлагает все новые подходы к решению этой задачи, однако до сих пор нет надежной универсальной методики, дающей гарантированный результат. Поэтому в большинстве случаев приходится опробовать различные методы.
В простейшем случае определить стоимость разработки ПО можно исходя из количественной оценки трудозатрат Т (в неких единицах, например человеко-месяцах или человеко-часах) и их удельной стоимости Ц:
С = Т × Ц.
Цена одной единицы трудозатрат для индустрии разработки ПО формируется, в основном, исходя из заработной платы и связанных с ней начислений. Как правило, другие составляющие имеют гораздо меньший удельный вес, и ими зачастую можно пренебречь.
Что касается самих трудозатрат, то их достоверное вычисление в сфере интеллектуальной деятельности, к которой, несомненно, относится разработка ПО, выполнить достаточно сложно. Простейший подход может быть основан на следующей линейной формуле:
Т = Р × П,
где Р - размер исходного кода ПО; П - временная производительность.
Эта примитивная формула активно применяется и по сей день, хотя ее несостоятельность была установлена довольно давно. Пожалуй, самой известной работой, в которой критикуется данный подход, является выдержавшая более двадцати изданий по-настоящему классическая книга Фредерика Брукса (Frederick Brooks) «Мифический человеко-месяц, или Как создаются программные системы», впервые увидевшая свет еще в 1977 г.