ЦЕЛЬ РАБОТЫ: изучение методов оценки метрических характеристик качества программных продуктов. Приобретение практических навыков по оценке сложности программных продуктов.
ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ
Существует множество разных подходов к оценке качества программ. С одной стороны, оценить качество объективно может только пользователь (причем такая оценка трудно формализуется). С другой – обеспечить необходимый уровень качества может только разработчик, добившись определенных характеристик конструкции и технологии создания программ. Эти характеристики также трудно формализуются и практически не соответствуют оценкам пользователей.
Взаимосвязь этих двух процессов возможна лишь при наличии формализованной модели оценки качества ПО и факторов его определяющих.
Качество ПО – это совокупность свойств, определяющих полезность изделия (программы) для пользователей в соответствии с функциональным назначением и предъявленными требованиями.
Оценка качества включает в себя два основных этапа: 1) получение информации о фактическом состоянии контролируемого объекта; 2) сопоставление этой информации с предъявленными требованиями, т.е.установление факта соответствия реальных свойств с требуемыми.
Шумакова Т.А. «Принципы и критерии качества маммографического исследования»
Следовательно, необходимо располагать некоторой системой измеряемых показателей качества, которая позволила бы сформулировать требования и контролировать их выполнение в процессе разработки ПО. Как правило, для построения такой оценки применяются иерархические многоуровневые модели. Позволяющие: 1) предоставить максимум информации непосредственным исполнителям, для выявления причин ухудшения той или иной характеристики качества; 2)определять требования к ПО на самых ранних стадиях разработки. Здесь важно отметить простоту формулировок и понятность требований
С иерархическими многоуровневыми моделями связано несколько определений:
Свойство программы — это её объективные особенности, проявляющиеся при её разработке, эксплуатации и (или) сопровождении.
Показатель качества программы – это понятие, отражающее определённую часть свойств программы и поддающееся интуитивной оценке.
Характеристика качества программы – это понятие, отражающее отдельные факторы (свойства), влияющие на качество программы и поддающиеся измерению.
Критерий качества – это численный показатель, характеризующий степень, в которой программе присущи оцениваемые свойства.
Основные требования к критериям качества ПО:
1. Критерий должен численно характеризовать основную целевую функцию программы.
2. Критерий должен обеспечивать возможность определения затрат (не только денежных), необходимых для достижения требуемого уровня качества, а также степени влияния на показатель качества различных внешних факторов.
3. Критерий должен быть по возможности простым, хорошо измеримым и иметь малую дисперсию.
Примеры критериев: Сложность, корректность, надёжность, трудоёмкость
Примеры свойств: число строк программы, количество точек входа, время подготовки исходных данных, общее время работы, время выдачи выходных результатов, количество разработчиков.
Качество программного обеспечения
Примеры свойств программ: субъективные свойства (время ввода исходных данных), объективные (количество операторов, количество строк, время работы программы).
Характеристики: субъективная характеристика (удобство интерфейса), объективная характеристика (точность результата).
Для измерения характеристик и критериев качества необходим соответствующий математический аппарат.
Источник: infopedia.su
Критерии оценки качества мобильных приложений
От качества мобильных приложений зависит удобство его использования для пользователей и популярность среди целевой аудитории приложения, рейтинг, количество установок, отзывы.
Перед созданием мобильного приложения разработчик исходит из двух основных аспектов:
— Целевая аудитория приложения (пол, возраст, сфера деятельности)
— Цель создания мобильного приложения
Мобильное приложение должно быть удобным целевой аудитории и выполнять ту цель, которая была поставлена при создании. Помимо этих основных аспектов мобильное приложение должно быть качественно сделано и быть не хуже приложений конкурентов, а возможно даже лучше. Оценку качества лучше выполнять по чётко сформулированным критериям.
1. Графический дизайн
Требования к дизайну мобильных приложений постоянно растут. Существуют популярные сейчас направления в дизайне и при разработке это надо учитывать, но при этом восприятие пользователем приложения не должно ухудшаться. Дизайн должен соответствовать целевой аудитории приложения.
Искажения в графическом дизайне могут возникнуть при использовании мобильного приложения на каких-то моделях смартфонов (особенно на устаревших моделях), поэтому постарайтесь протестировать приложение на этих устройствах.
2. Удобство для пользователей
Мобильное приложение может иметь множество экранов связанных между собой. Очень важно правильно организовать переходы между экранами, чтобы пользователю была интуитивна понятна логика работы мобильного приложения. На удобство использования сказывается удачное размещение активных элементов управления, например таких как кнопки или иконки, при нажатии на которые происходит переход на соответствующие экраны. Понятно ли назначение кнопок и смысл иконок?
Нужно обратить внимание на процесс ввода текста и цифр в поля на экранах. Понятно ли работает выход из режима ввода текста?
Удобство использования мобильного приложения может иметь существенные отличия для Android и iOS-устройств, поэтому для точного оценки этого критерия необходимо тестирование мобильного приложения на обоих платформах.
3. Функциональность
Количество и полнота функционала мобильного приложения. Проверяйте функционал по списку функций технического задания. Не возникает ли у пользователя необходимости в дополнительном функционале или в добавлении дополнительных возможностей в уже существующих функциях?
При оценке функциональности прежде всего надо обратить внимание на отсутствие сбоев в работе. Не создает ли реализация конкретной функции мобильного приложения ощущение у пользователя, что в данном месте приложение работает с ошибкой?
Могут быть нюансы в работе функций мобильного приложения при использовании телефонов разных моделей, поэтому проведите тестирование на как можно большем количестве различных моделей телефонов.
4. Степень агрессивности к пользователю
Агрессивность приложения может выражаться в избыточных требованиях к пользователю, которые могут излишне напрягать или заставлять пользователя делать действия, которые не имеют существенного значения. Например, избыточное количество полей для ввода, не обоснованное обязательность ввода значений в поля на экране.
Приложение может быть агрессивно, когда для того, чтобы сделать какое-либо действие пользователь должен открыть слишком много подряд идущих экранов или по используемой цветовой гамме.
4. Ценность
Для кого и для чего создано мобильное приложение и какую ценность оно несёт пользователю? Смогло ли мобильное приложение выполнить цель, поставленную перед его созданием?
4. Производительность и стабильность работы
Оцените скорость работы мобильного приложения. Не слишком ли долго загружаются экраны? Необходимо посмотреть, как будет работать приложение через день, неделю не возникнет ли проблем со стабильностью его работы?
Тестирование мобильного приложения
При тестировании мобильного приложения необходимо проверить приложение по всем выше перечисленным критериям. В идеале в тестировании должны принять участие люди разного пола, возраста. При тестировании нужно главное оценить — это соответствие мобильного приложения его целевой аудитории. Чем проще в использовании приложение, тем шире может быть аудитория, использующих его людей.
Источник: nordcloudsoft.com
Принципы управления качеством программ
Тема качества программного обеспечения сегодня весьма популярна, однако на фоне разнообразного толкования качества трудно получить целостное представление о проблеме и основных принципах управления качеством. Возможно, предлагаемый в статье обзор методов повышения качества и подход анализа качества поможет по-иному взглянуть на эту задачу.
Согласно ГОСТ Р ИСО 9000-2001, качество— это «степень соответствия присущих характеристик продукта требованиям», что для области разработки программного обеспечения может быть истолковано не совсем верно. Разработка требований применительно к ПО есть неотъемлемая часть самого процесса разработки программ. Качество требований к программному продукту напрямую влияет на качество самого этого продукта. Иными словами, если требования к программному продукту некачественны, то сам продукт, разработанный по этим требованиям, также будет некачественным даже в случае идеального соответствия. Если слово «требования» в определении ГОСТа заменить на «цели проекта», то все встает на свои места.
Итак, качество программного продукта— это степень соответствия функциональных, технических, эксплуатационных характеристик разработанного программного продукта целям, которые были поставлены перед началом разработки этого продукта. Его качество— некая функция от многих переменных, в том числе следующих:
функциональность (насколько программный продукт полезен для пользователя);
качество пользовательского интерфейса (удобство использования, легкость в обучении);
надежность (отсутствие дефектов в программном продукте, устойчивость к сбоям);
производительность, потребление ресурсов, требования к внешней среде;
качество информационной поддержки (документация);
сопровождаемость (качество дизайна и кода, внутреннее качество).
Другие критерии можно найти, например, в [1]. Компания-разработчик определяет свои стандарты качества для каждого критерия и для каждого программного проекта. При оценке качества необходимо иметь возможность количественно оценить каждый из критериев. В таблице приведена зависимость конкретного вида деятельности и критериев качества.
На качество конечного продукта влияют все фазы и виды деятельности проекта, и от того, насколько хорошо и качественно мы работаем на каждой фазе проекта (а не только, например, на фазе тестирования), зависит, насколько качественным получится разрабатываемый продукт. Другими словами, качество процесса разработки определяет качество продукта [1, 2].
Для анализа качества введем обобщенный критерий— дефект, определяющий любое отклонение от установленных для проекта стандартов качества. Например, недостаток функциональности или лишняя функциональность— дефект; неудобный интерфейс— дефект; плохой дизайн или грязный код, который негативно скажется на сопровождаемости,— дефект; неприемлемая производительность— дефект; некорректная работа программы— частный случай дефекта; орфографическая ошибка в документации— дефект.
Дефекты можно классифицировать по следующим параметрам:
тип (определяется фазой разработки или активностью, на которой был внесен дефект);
критичность (насколько критично наличие дефекта в программном продукте);
приоритет (насколько важно исправить дефект);
сложность (насколько трудоемко исправить дефект);
Имея подобный обобщенный показатель, становится проще оценивать и анализировать качество разрабатываемого программного продукта, а также качество самого процесса разработки. Можно считать количество дефектов или сумму их весов (по какому-либо параметру), можно оценивать плотность дефектов на единицу объема продукта, анализировать, какие фазы процесса являются наиболее проблемными для нас и т.д., сведя борьбу за качество к борьбе с дефектами.
Управление качеством программного продукта
Можно нарисовать график изменения количества дефектов в проекте с течением времени. На рис. 1 приведен график для случая водопадной модели жизненного цикла проекта и традиционного подхода к качеству программного продукта, где основной упор делается на тщательное тестирование.
Верхняя линия (рис. 1)— примерное количество внесенных дефектов на текущий момент времени, а нижняя— количество найденных и исправленных дефектов на текущий момент времени (предполагается, что дефекты исправляются практически сразу после обнаружения). Разница между линиями в каждый момент времени отображает количество имеющихся на данный момент дефектов. Чем меньше будет эта разница в конце проекта, тем качественнее продукт.
Эффективность поиска дефектов
Рассмотрим, например, фазу системного тестирования, в ходе которой обнаруживается некое количество дефектов Dfound, но сколько-то дефектов остается ненайденным на момент завершения фазы Dmissed (рис. 2). Общее число дефектов, прошедших через фазу, будет равно Dfound + Dmissed.
Отношение найденных дефектов к их общему числу, выраженное в процентах, назовем эффективностью поиска дефектов [2]— это одна из основных характеристик качества процесса разработки, которую необходимо постоянно контролировать. Для каждой фазы, в ходе которой находятся и исправляются дефекты, при стабильном и предсказуемом процессе и прочих равных условиях эту величину можно считать приблизительно постоянной, что позволяет количественно оценивать уровень качества (выраженный в количестве ненайденных дефектов) для текущего и для планируемых проектов.
Эффективность поиска дефектов можно рассматривать как для отдельных фаз, так и для всего жизненного цикла разработки. При этом эффективности отдельных фаз определяют эффективность для всего жизненного цикла. Каждую фазу поиска дефектов можно рассматривать как своего рода фильтр, который удерживает некую часть дефектов, а весь жизненный цикл— как систему фильтров [2]. Если на ранних этапах жизненного цикла стоят плохие фильтры, которые пропускают много дефектов, то эти дефекты накапливаются, и, чтобы их хорошо отфильтровать, в конце жизненного цикла (фаза тестирования) будет необходим очень хороший фильтр.
Дефекты со временем имеют тенденцию не только накапливаться, если не предпринимать ранних мер по их устранению, но и увеличивать стоимость их исправления, причем часто эта зависимость— экспоненциальная. Для водопадной модели жизненного цикла эта зависимость хорошо иллюстрируется графиком из рис. 3. Для итерационной модели жизненного цикла картина будет похожая, изменятся только надписи: вместо названий фаз будут номера итераций.
Комплексный подход к управлению качеством
Полагаясь только на одно, даже и очень тщательное, тестирование, проблему качества не решить. Если не предпринимать никаких мер по борьбе с дефектами вплоть до этапа тестирования, то к началу тестирования в проекте может накопиться слишком много дефектов, поэтому дефекты надо искать и исправлять постоянно, на протяжении всего жизненного цикла проекта. Кроме того, надо принять все меры по предотвращению или недопущению дефектов.
Применение методов поиска дефектов на протяжении всего жизненного цикла проекта поднимает кривую найденных дефектов вверх, а применение методов предотвращения дефектов опускает кривую вносимых дефектов вниз (рис. 4). Таким образом, количество ненайденных дефектов на протяжении всего жизненного цикла уменьшается, и как результат уменьшается количество ненайденных дефектов в конце проекта.
Методы поиска и предотвращения дефектов
Известно немало методов поиска дефектов.
Ручной анализ, или обзор разрабатываемых артефактов. Персональные проверки (personal review) [2], формальные инспекции [2, 3], групповые обзоры (walkthrough), парное программирование [4], групповое проектирование и т.п.
Автоматическая статическая проверка. Компиляция (помимо явных дефектов компилятор умеет находить неявные), статический анализ кода с помощью специальных анализаторов, проверка на соблюдение принятого код-стандарта и стиля.
Автоматизированное тестирование. Модульное или блочное тестирование (unit testing) [4, 5], функциональное (комплексное) тестирование, тестирование графического интерфейса пользователя, тестирование производительности, стресс-тестирование, использование утверждений (asserts) [6] и т.д.
Ручное тестирование Интеграционное, системное, сравнительное, верификация требований, «охота за ошибками» (bug bash), пошаговая трассировка [6] и т.д.
Эффективная стратегия поиска дефектов состоит в применении комбинации нескольких методов, каждый из которых будет иметь свой собственный уровень эффективности, выраженный в процентах. Согласно данным [1], тестирование имеет сравнительно низкую эффективность поиска дефектов (30-40%), а для того, чтобы сделать ее высокой, необходимо увеличить стоимость процесса тестирования в разы (эффективность бета-тестирования при количестве тестировщиков более 1000 составляет около 75%).
Вряд ли возможно разрабатывать ПО вообще без дефектов, но попытаться уменьшить число вносимых дефектов стоит попробовать. Перечислим наиболее известные методы предотвращения дефектов.
Прототипирование. Создание и опробование модели разрабатываемой системы с целью проверить ее характеристики и выявить неверные предположения и решения, которые могли бы привести к серьезным дефектам (и переделкам) при разработке [6].
Использование стандартов на все виды продуктов, производимых в ходе разработки ПО (требования, дизайн, код, различная документация и т.д.).
Применение компонентного подхода [6].
Использование готовых компонентов— чем меньше приходится разрабатывать новых решений, тем меньше ошибок.
Предварительная разработка тест-кейсов (до этапа кодирования) позволяет глубже понять требования к разрабатываемой системе и лучше спроектировать ее. Частный случай этого подхода— Test-Driven Development, при котором модульные тесты разрабатываются не после, а до кодирования.
Рефакторинг кода, то есть приведение его в надлежащий вид [5].
Регулярный анализ причин появления наиболее серьезных дефектов и поиск путей устранения этих причин. Это может происходить на периодических собраниях команды разработчиков [3], или можно проводить такой анализ для каждого серьезного дефекта, найденного на этапах системного тестирования или после внедрения. Результатом такого анализа должны быть модификации процесса разработки, направленные на устранение причин появления дефектов или, как минимум, способствующие более раннему обнаружению подобных дефектов.
Стоит также упомянуть человеческий фактор— никакие методы не заменят профессионализм и опыт разработчиков и менеджеров. Опытные профессионалы, как правило, делают меньше ошибок, что дает хороший задел для качественной разработки.
Итерационный жизненный цикл
Рассмотрим итерационный жизненный цикл, состоящий из пяти итераций, каждую из которых можно рассматривать как маленький, но полный водопадный жизненный цикл (рис. 5).
Предположим, эффективность поиска дефектов каждого из водопадных циклов составляет 50%, и на каждой итерации вносится одинаковое количество дефектов. Чему будет равна эффективность поиска дефектов итерационного цикла, состоящего из пяти последовательных итераций? После первой итерации эффективность будет равна 50%; после второй— 62,5%; после третьей— 70,8%; после четвертой— 76,6%; после пятой эффективность поиска дефектов всех пяти итераций будет равна 80,6%.
В реальной жизни эффективности поиска дефектов на разных итерациях, скорее всего, будут отличаться, что связано с неоднородностью деятельностей на разных итерациях, но в любом случае налицо явный прогресс в качестве перед простым водопадным жизненным циклом. На каждой последующей итерации находятся дефекты не только текущей итерации, но и оставшиеся дефекты предыдущих итераций. В результате общая эффективность поиска дефектов увеличивается.
Таким образом, получается, что добиться улучшения качества можно не только введением дополнительных методов раннего поиска дефектов (таких, как инспекции, обзоры и т.п.), но также и путем перехода от водопадного к итерационному жизненному циклу разработки ПО.
Цена качества
Может показаться, что применение множества различных методов повышения качества ПО увеличит стоимость разработки, однако это верно лишь в краткосрочной перспективе (пока процесс их использования не стабилизировался) либо при неграмотном использовании методов. В долгосрочной же перспективе комплексное применение методов повышения качества не только не удорожает разработку, но может удешевить ее.
Во-первых, чем раньше был найден дефект, тем дешевле обходится его исправление. Поэтому эффективное применение методов раннего поиска дефектов способствует снижению стоимости проекта.
Во-вторых, методы поиска дефектов помимо эффективности характеризуются также средней скоростью нахождения дефектов. Согласно статистическим данным, например из [1], этот показатель у методов тестирования в несколько раз хуже, чем у методов раннего поиска дефектов. Это означает, что, тратя время на поиск дефектов на ранних фазах, мы экономим больше времени на предстоящем тестировании.
Процесс управления качеством
Для управления качеством недостаточно простого использования различных методов его повышения— необходимо их осознанное систематическое применение, которое стало бы неотъемлемой частью процесса разработки ПО, ориентированного на качество. Необходим постоянный контроль качества разрабатываемого ПО через метрики качества (плотность дефектов, размер переделок, среднее время между отказами и др.), а также контроль качества отдельных подпроцессов, составляющих целостный процесс разработки.
Методы, которые хорошо работали вчера, сегодня могут представлять собой пустую трату времени. У каждого проекта может быть своя специфика, требующая иного набора методов повышения качества. Например, одни проекты (особо критичные) могут потребовать тщательнейшего тестирования всех тест-кейсов, в других (когда тестирование очень трудоемко) больше внимания следует уделять инспекциям, третьи (инновационные) потребуют предварительного прототипирования, четвертые (критичные к ресурсам) потребуют стресс-тестирования и т.д.. Если постоянно не контролировать эффективность методов, то со временем она может значительно снизиться.
Литература
Макконнелл С., Совершенный код. Мастер-класс / Пер. с англ.— М.: «Русская Редакция»; СПб.: Питер, 2005.
Humphrey, Watts S., A discipline for software engineering, ISBN 0-201-54610-8. Addison-Wesley Longman, 1995.
Humphrey, Watts S., Introduction to Team Software Process, ISBN 0-201-47719-X. Addison Wesley Longman, 2005.
Бек К., Экстремальное программирование. Пер. с англ.— СПб.: Питер, 2002.
Фаулер М., Рефакторинг: улучшение существующего кода. Пер. с англ.— СПб.: Символ-Плюс, 2005.
Хант Э., Томас Д., Программист-прагматик. Путь от подмастерья к мастеру. Пер. с англ.— М.: Издательство «Лори», 2004.
Пример управления качеством ПО
Компания CQG является одним из поставщиков биржевой информации и программных продуктов для биржевой торговли. В компании используются следующие методы повышения качества ПО.
Персональные проверки.
Обязательные формальные инспекции всех артефактов (требования, архитектура, проектные модели, тест-планы, код).
Автоматизированное модульное тестирование.
Различные виды тестирования вручную (интеграционное, системное, релиз, верификация требований, «охота за ошибками»).
Автоматизированное функциональное тестирование (для некоторых систем).
Обязательные стандарты на все артефакты: планы проектов, требования, дизайн, тест-планы, код.
Прототипирование на самых ранних стадиях проектов.
Регулярные собрания команд разработчиков с целью анализа причин появления наиболее серьезных дефектов и поиска путей устранения этих причин.
Контроль качества процесса и проектов осуществляется регулярно с помощью следующих метрик.
Плотности дефектов на 1000 строк кода, найденных на разных стадиях, таких как инспекции кода, интеграционное, системное, релиз-тестирование.
Эффективность инспекций (плотность найденных замечаний, скорость проверки, процент найденных дефектов, покрытие кода инспекциями).
Процент переделок (размер кода для исправления дефектов по отношению к общему числу разработанного кода).
Покрытие кода юнит-тестами.
Покрытие кода формальными требованиями.
При планировании каждого проекта обязательно составляется план качества, отражающий особенности проекта с точки зрения обеспечения качества. В этом плане приводится перечень необходимых методов контроля качества, определенные параметры этих методов и ожидаемые характеристики качества будущего продукта, которых следует достигнуть.
Использование разнообразных методов повышения качества и регулярный контроль качества процесса позволяет CQG обходиться довольно малым количеством тестировщиков по отношению к количеству разработчиков. При этом основной целью работы отдела тестирования является не поиск дефектов в разработанном ПО, а проверка его высокого качества.
Все новые разработчики, приходящие в компанию, проходят через обязательные тренинги по процессам, методам и стандартам, принятым в компании, а также по используемым инструментам автоматизации управления разработкой программного обеспечения.
Источник: www.osp.ru