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

Главная Форумы Программирование Технология программирования Управление качеством программного обеспечения

В этой теме 0 ответов, 1 участник, последнее обновление  Васильев Владимир Сергеевич 1 год назад.

  • Автор
    Сообщения
  • #3112

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

    Основными стандартами в области качества являются международные стандарты серии ИСО 9000 [1], ИСО 8402 [2], а также, ГОСТ 15467-79 [3].

    Заметка состоит из двух частей:

    1. приводятся основные определения, в соответствии со стандартами (ISO, ГОСТ);
    2. обсуждаются вопросы разработки программного обеспечения (ПО):
      • приводятся примеры критериев качества ПО;
      • рассматриваются итерационный и водопадный жизненные циклы ПО в контексте обеспечения качества;
      • описаны способы устранения дефектов, используемые при разработка ПО.

    1 Управление качеством

    Согласно ГОСТ 15467-79, управление качеством продукции — действия, осуществляемые при создании и эксплуатации или потреблении продукции в целях установления, обеспечения и поддержания необходимого уровня её качества.

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

    Качество продукции связано с объёмом брака (количеством дефектов) [4, 5]. При этом, дефектом называют любое отклонение от требований, предъявляемых к производимой продукции. Набор требований зависит от типа производимой продукции, в следующем разделе более подробно рассмотрен случай, если продуктом является программное обеспечение.

    2 Особенности управления качеством программного обеспечения

    Перед началом разработки ПО, к нему должны быть сформулированы требования. Требования фиксируются в техническом задании, согласно ГОСТ Р ИСО/МЭК 9126 [6] к ним относят, например:

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

      Разработка архитектуры ПО должна быть произведена перед началом кодирования. Во время кодирования необходимо постоянно следить за соблюдением соглашений. Документация может разрабатываться как одновременно с кодированием, так и после него. Таким образом, управление качеством ПО производится непрерывно, в течении всего жизненного цикла ПО [7].

      2.1 Жизненный цикл программного обеспечения

      Согласно ANSI/IEEE Std 610.12-1990 [9], жизненный цикл ПО – период времени, от момента принятия решения о необходимости создания программного продукта до момента его утилизации. Жизненный цикл делится на множество этапов, включая разработку и использование ПО. Выделяют несколько моделей жизненного цикла, в зависимости от того, каким образом он делится на этапы [8].

      На рисунке схематично изображены каскадная и итерационная модели жизненного цикла:
      software-quality-control

      В обоих моделях, разработку разделяют на следующие этапы:

      1. формулирование требований к продукту;
      2. проектирование;
      3. кодирование;
      4. отладка;
      5. внедрение;
      6. поддержка.

      Переход к следующему этапу производится лишь после завершения работ на предыдущем этапе.

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

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

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

      В итеративной модели поиск дефектов осуществляется многократно — он обязательно выполняется на каждой итерации.

      2.2 Методы устранения дефектов

      В ряде статей [5, 6] подчёркивается важность комплексного подхода к управлению качеством ПО, при этом, под комплексным подходом имеется ввиду необходимость поиска и устранения дефектов, на каждом этапе жизненного цикла ПО.

      Рассчитано [6], что если выполнять поиск дефектов на каждом этапе, допустим, последовательной модели жизненного цикла, то к моменту внедрения проекта дефектов будет значительно меньше (если положить эффективность поиска дефектов на каждом этапе равной 50%, то при внедрении будет устранено 80.6% дефектов). Однако, тестирование ПО при последовательном жизненном цикле затруднено, т. к. нет продукта, к которому можно применить тесты, однако комплексный подход к управлению качеством ПО возможен при итеративном жизненном цикле.

      Основными методами поиска дефектов являются отладка и тестирование.

      Для тестирования ПО необходима разработка тестов. Если ПО имеет модульную архитектуру, то к нему возможно написание и применение юнит-тестов [10], при этом, каждый модуль программы тестируется отдельно. Такой подход позволяет локализовать модуль, в котором заключён дефект.

      В настоящее время широко применяется технология покрывающего тестирования (разработка через тестирование, test-driven development, TDD) [11], при этом, наборы тестов разрабатываются до начала непосредственной разработки, а при внесении любого изменения в ПО проверяется его соответствие тестам.

      Помимо тестирования может применяться верификация систем. В настоящее время, чаще всего используется верификация моделей (Model checking) [12]. Однако, верификация – очень сложный и дорогостоящий процесс, который могут позволить себе лишь очень крупные компании.

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

      Повысить качество разрабатываемого кода возможно также за счет других методов, таких как неформальный обзор кода (при этом каждый разработчик просматривает результаты работы другого разработчика и указывает на недостатки) или, например парное программирование [13].

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

      На этапе проектирования и разработки документации широко применяется унифицированный язык моделирования (UML) [15]. UML яявляется международным стандартом, поэтому упрощает комуникацию между разработчиками и заказчиками ПО, в следсвтии чего сокращает количество дефектов, допускаемых на этапе проектирования, а также, повышает качество документации.

      Значительно сократить количество дефектов, а следовательно, и повысить качество ПО возможно за счет повторного использования кода, стандартных архитектурных решений, эволюционного подхода к разработке ПО. Под эволюционным подходом [16] понимается такой подход к разработке, при котором в уже написанный и отлаженный код не вносятся изменения (а следовательно, не добавляются дефекты), при этом не только поддерживается определенный стиль кодирования, но и необходимо применение специальных архитектурных решений на этапе проектирования.

      Под стандартными архитектурными решениями имеются введу шаблоны проектирования (design pattern) [17], т.е. архитектные конструкции, являющиеся решением некоторых часто возникающих проблем. За счет того, что решения являются стандартными и широко известными, упрощается процесс разработки и сопровождения системы.

      Методы поиска дефектов имеют различную эффективность и стоимость, так например, неформальный обзор кода является достаточно дешевым методом, при этом его эффективность поиска дефектов составляет 35%, бета-тестирование (при числе пользователей более 1000) является дорогим методом, т.к. Необходимо привлечение пользователей, при этом его эффективность составляет 75% [5].

      Список литературы по качеству программного обеспечения

      1. Международный стандарт ISO 9000:2005 «Системы менеджмента качества. Основные положения и словарь» М.: Стандартинформ, 2006
      2. Международный стандарт ISO 8402:1994 «Управление качеством и обеспечение качества — Словарь» — М.: ВНИИС
      3. ГОСТ 15467-79 Управление качеством продукции. Основные понятия. Термины и определения. — М.: Издательство стандартов, 1979
      4. Савкин В., Принципы управления качеством программ // Открытые системы. – 2008. – №6.- С.49-53. – С. 2008
      5. Основные принципы управления качеством программного обеспечения [Электронный ресурс], режим доступа: http://vsavkin.livejournal.com/6050.html
      6. Оценка программной продукции. Характеристики качества и руководства по их применению. ГОСТ Р ИСО/МЭК 9126-93 – М.: Изд-во стандартов,1994. – 15 с.
      7. Вайнштейн В., Управление качеством в процессах разработки программного обеспечения // Компьютера.-2003.- №4.
      8. ГОСТ 12207 ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств, М.: Росстандарт, 1999.
      9. IEEE-STD-610 ANSI/IEEE Std 610.12-1990, «IEEE Standard Glossary of Software Engineering Terminology», February 1991.
      10. The evolution of Unit Testing Syntax and Semantics [Электронный ресурс], режим доступа: https://weblogs.asp.net/rosherove/the-evolution-of-unit-testing-and-syntax
      11. Бек К. Экстремальное программирование. – Спб.: Питер, 2002.
      12. Вельдер С.Э., Шалыто А.А. Верификация простых автоматных программ на основе метода Model Сhecking / Материалы XV научно-методической конференции «Высокие интеллектуальные технологии и инновации в образовании и науке». – СПбГПУ, 2008. – С. 285–288. [Электронный ресурс]. – Режим доступа: http://is.ifmo.ru/download/2008-02-25_politech_verification.pdf
      13. Nick V. Flor Globally distributed software development and pair programming (англ.) // Communications of the ACM. — 2006. — Т. 49. — № 10. — С. 57-58.
      14. Doxygen, официальный сайт. [Электронный ресурс]. – Режим доступа: http://www.stack.nl/~dimitri/doxygen/
      15. ISO/IEC 19501:2005 Информационные технологии. Открытая распределенная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2
      16. Легалов А.И. Швец Д.А. Процедурный язык с поддержкой эволюционного проектирования. – Научный вестник НГТУ, № 2 (15), 2003. С. 25-38.
      17. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приёмы объектно-ориентированного проектирования. Паттерны проектирования. – СПб.: Питер, 2000.

Для ответа в этой теме необходимо авторизоваться.