Опубликован: 18.09.2006 | Уровень: специалист | Доступ: платный | ВУЗ: Московский государственный университет имени М.В.Ломоносова
Лекция 5:

Качество ПО и методы его контроля

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >

Помимо перечисленных характеристик и атрибутов качества, стандарт ISO 9126:2001 определяет наборы метрик для оценки каждого атрибута. Приведем следующие примеры таких метрик.

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

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

  • Что ПО должно делать, например:
    • позволять клиенту оформить заказы и обеспечить их доставку;
    • обеспечивать контроль качества строительства и отслеживать проблемные места;
    • поддерживать нужные характеристики автоматизированного процесса производства, предотвращая аварии и оптимальным образом используя имеющиеся ресурсы.
  • Насколько оно должно быть надежно, например:
    • работать 7 дней в неделю и 24 часа в сутки;
    • допускается неработоспособность в течение не более 3 часов в год;
    • никакие введенные пользователями данные при отказе не должны теряться.
  • Насколько им должно быть удобно пользоваться, например:
    • покупатель должен, зная название товара и имея средние навыки работы в Интернет, находить нужный ему товар за не более чем 2 минуты;
    • инженер по специальности "строительство мостов" должен в течение одного дня уметь разобраться в 80% функций системы.
  • Насколько оно должно быть эффективно, например:
    • поддерживать обслуживание до 10000 запросов в секунду;
    • время отклика на запрос при максимальной загрузке не должно превышать 3 с;
    • время реакции на изменение параметров процесса производства не должно превышать 0.1 с;
    • на обработку одного запроса не должно тратиться более 1 MB оперативной памяти.
  • Насколько удобно должно быть его сопровождение, например:
    • добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;
    • добавление поддержки нового этапа процесса производства не должно стоить более $20000.
  • Насколько оно должно быть переносимо, например:
    • ПО должно работать на операционных системах Linux, Windows XP и MacOS X;
    • ПО должно работать с документами в форматах MS Word 97 и HTML;
    • ПО должно сохранять файлы отчетов в форматах MS Word 2000, MS Excel 2000, HTML, RTF и в виде обычного текста;
    • ПО должно сопрягаться с существующей системой записи данных о заказах.

Приведенные атрибуты качества закреплены в стандартах, но это не значит, что они вполне исчерпывают понятие качества ПО. Так, в стандарте ISO 9126 отсутствуют характеристики, связанные с мобильностью ПО (mobility), т.е. способностью программы работать при физических перемещениях машины, на которой она работает. Вместо надежности многие исследователи предпочитают рассматривать более общее понятие добротности (dependability), описывающее способность ПО поддерживать определенные показатели качества по основным характеристикам ( функциональности, производительности, удобству использования ) с заданными вероятностями выхода за их рамки и определенным максимальным ущербом от возможных нарушений. Кроме того, активно исследуются понятия удобства использования, безопасности и защищенности ПО, — они кажутся большинству специалистов гораздо более сложными, чем это описывается данным стандартом.

Методы контроля качества

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

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

Эффективность верификации и валидации, как и эффективность разработки ПО в целом, зависит от полноты и корректности формулировки требований к программному продукту.

Основой любой системы обеспечения качества являются методы его обеспечения и контроля. Методы обеспечения качества [9] представляют собой техники, гарантирующие достижение определенных показателей качества при их применении. Мы будем рассматривать подобные методы на протяжении всего курса.

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

  • Методы и техники, связанные с выяснением свойств ПО во время его работы.

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

  • Методы и техники определения показателей качества на основе симуляции работы ПО с помощью моделей разного рода.

    К этому виду относятся проверка на моделях (model checking), а также прототипирование (макетирование), используемое для оценки качества принимаемых решений.

  • Методы и техники, нацеленные на выявление нарушений формализованных правил построения исходного кода ПО, проектных моделей и документации.

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

  • Методы и техники обычного или формализованного анализа проектной документации и исходного кода для выявления их свойств.

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

Далее мы несколько подробнее рассмотрим тестирование и проверку на моделях как примеры методов контроля качества.

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >
Владислав Нагорный
Владислав Нагорный

Подскажите, пожалуйста, планируете ли вы возобновление программ высшего образования? Если да, есть ли какие-то примерные сроки?

Спасибо!

Лариса Парфенова
Лариса Парфенова

1) Можно ли экстерном получить второе высшее образование "Программная инженерия" ?

2) Трудоустраиваете ли Вы выпускников?

3) Можно ли с Вашим дипломом поступить в аспирантуру?

 

Андрей Швецов
Андрей Швецов
Россия, Александровск, школа-гимназия №2 им. Островского, 2005
Анна Оганян
Анна Оганян
Россия, Москва, МГОУ