Тема 1 «Основные понятия и характеристики качества программного обеспечения»
Качество – философская категория: неопределимая от бытия объекта его существенная определенность, благодаря которой он является именно этим, а не иным объектом.
Качество продукции – критическая оценка потребителем степени соответствия её свойств, показателей качества, индивидуальным и общественным ожиданиям, обязательным нормам в соответствии с её назначением.
Свойство продукции – объективные стороны объекта без оценивания важности этих свойств для потребителя.
Полезность продукции – способность продукции приносить пользу и удовлетворять конкретного потребителя.
ISO - International Organization for Standardization - Международная организация по стандартизации
Качество – полнота свойств и характеристик продукта, процесса или услуги, обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям.
IEEE - Institute of Electrical and Electronic Engineers - Институт инженеров по электротехнике и электронике
Качество программного обеспечения – степень, в которой оно обладает требуемой комбинацией свойств
Качество программного обеспечения – совокупность свойств, характеризующих способность программного обеспечения удовлетворять потребностям в соответствии с предназначением.
На данный момент наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки.
Помимо перечисленных характеристик и атрибутов качества, стандарт ISO 9126:2001 определяет наборы метрик для оценки каждого атрибута. Приведем следующие примеры таких метрик.
-
Полнота реализации функций — процент реализованных функций по отношению к перечисленным в требованиях. Используется для измерения функциональной пригодности.
-
Корректность реализации функций — правильность их реализации по отношению к требованиям. Используется для измерения функциональной пригодности.
-
Отношение числа обнаруженных дефектов к прогнозируемому. Используется для определения зрелости.
-
Отношение числа проведенных тестов к общему их числу. Используется для определения зрелости.
-
Отношение числа доступных проектных документов к указанному в их списке. Используется для измерения удобства проведения анализа.
-
Наглядность и полнота документации. Используется для оценки понятности.
Свойства программы – особенности, объективно присущие программе, которые проявляются в её жизненной цикле (разработке, применении, сопровождении).
Характеристика программы – понятие, отражающее проявление отдельного измеримого фактора присущего программе свойства.
Характеристика программы – проявляемый и измеримый атрибут свойства.
Измерение (оценка) одной или нескольких характеристик программы даёт представление о том, насколько программе присуще то или иное свойство.
Обеспечение качества – совокупность планируемых и систематически проводимых мероприятий, необходимых для уверенности в том, что продукция или процессы удовлетворяют определенным требованиям к качеству.
Системы качества, каждая из которых включает совокупность организационной структуры, ответственности, процедур, процессов или ресурсов, обеспечивающую осуществление общего руководства качеством.
Межгосударственный стандарт ГОСТ 28806-90 Качество программного средства – совокупность свойств программного средства, которые обуславливают его пригодность удовлетворять заданные или подразумеваемые потребности в соответствии с его предназначением.
Применимая к программным средствам система обеспечения качества – совокупность методов и средств организации управляющих и исполнительных подразделений предприятия, участвующих в проектировании, разработке и сопровождении комплексов программ с целью придания им свойств, обеспечивающих удовлетворение определенный потребностей заказчиков и потребителей при минимальном или допустимом расходовании ресурсов.
Различия фактических и требуемых показателей качества объектов или процессов – дефекты или ошибки. Они являются первичными стимулами для принятия и реализации решений по изменению измеряемых значений качества.
Факторы, влияющие на качество ПС
Ошибка – дефект, погрешность или неумышленное искажение объекта или процесса.
Поскольку при разработке программ необходимо сначала понять задачу, затем придумать ее решение и закодировать его в виде программы, то, соответственно, основных источников ошибок три:
- Неправильное понимание задач.
- Неправильное решение задач.
- Неправильный перенос решений в код.
Объекты уязвимости:
- динамический вычислительный процесс обработки данных, автоматизированной подготовки решений и выработки управляющих воздействий на потребителей обработанной информации;
- информация, накопленная в базах данных, отражающая объекты внешней среды, и процессы её обработки;
- объектный код программ, исполняемых вычислительными средствами в процессе функционирования ПС;
- информация, выдаваемая потребителям и на исполнительные механизмы, являющаяся результатом обработки исходных данных и информации, накопленной в базе данных.
Дестабилизирующие факторы:
- Внутренние (присущие самим объектам уязвимости)
-
Системные ошибки при постановке целей и задач
-
Алгоритмические ошибки разработки
-
Ошибки программирования в текстах программ и описаниях данных, в документации
-
Недостаточную эффективность методов и средств защиты программ от сбоев и отказов
-
Недостаточная эффективность методов и средств обеспечения качества и надежности функционирования ПС
- Внешние (обусловлены средой, в которой эти объекты функционируют)
-
Ошибки персонала в процессе эксплуатации ПС
-
Искажения в каналах информации, поступающей и передаваемой потребителям
-
Недопустимые для конкретной ИС характеристики потоков внешней информации
-
Сбои и отказы в аппаратуре
-
Изменения состава и конфигурации аппаратуры ИС за пределы, отраженные в эксплуатационной документации
Степень влияния всех внутренних дестабилизирующих факторов, а также некоторых внешних угроз на качество ПС определяется в наибольшей степени качеством технологий проектирования, разработки, сопровождения и документирования ПС и их основных компонентов.
При ограниченных ресурсах на разработку ПС для достижения заданных требований качества необходимо управление обеспечением качества в течение всего жизненного цикла программ и данных.
Общие факторы, влияющие на качество продукции:
-
Общественные ожидания, субъективные настроения потребителей
-
Качество проекта (совершенство организации)
-
Качество исполнения (совершенство технологий)
-
Уровень конкуренции рынка
Качество функционирования – множество свойств, обуславливающих пригодность ПС обеспечивать надежное и своевременное представление требуемой информации потребителю для её дальнейшего использования по назначению.
Каждая характеристика качества может эффективно использоваться, если определена её метрика, мера и шкала и может быть указан способ её измерения или оценивания, а также сопоставления с требующимся значением. Они должны отражать функциональную пригодность для применения с заданными целями.
На практике важно оценивать качество программ не только в завершенном виде, но и в процессе их проектирования, разработки и сопровождения.
Достижимое качество ПС определяется методами и инструментальными средствами, применяемыми для обеспечения всего их жизненного цикла.
Метрики качества программных средств
Фактор качества – свойство, в той или иной степени обуславливающие качество программного обеспечения.
При оценке качества учитывают несколько факторов. Для получения численной оценки фактора качества используют один или несколько критериев качества.
Критерий качества – понятие, признак или численный показатель, характеризующий оцениваемый фактор качества.
Критерий качества может быть представлен имеющим физический смысл вычислимым выражением, составленным из характеристик качества, значением которого является показатель качества.
Для вычисления значения критерия используют одну или несколько метрик.
Метрика – мера количественной оценки качества ПО по заданному критерию, система или способ измерений качества программного обеспечения.
Оценочный элемент – измеримая характеристика программного обеспечения, имеющая численное значение в избранной измерительной шкале
Показатель качества – численное значение критерия качества, определяющее степень, в которой программе присуще определенное критерием свойство.
В соответствии с ГОСТ 15467-79 под показателем качества следует понимать количественную характеристике одного или нескольких свойств программной продукции, составляющих её качество применительно к определенным условиям её создания и эксплуатации.
Базовое значение показателя качества – реально достижимое значение показателя, отражающее современный уровень развития программного обеспечения.
Оценка качества программного обеспечения – совокупность операций, включающих выбор номенклатуры (состава) показателей качества, определения значений этих показателей и сравнения их с базовыми значениями.
Сертификация – процесс определения соответствия программного обеспечения действующему стандарту качества.
Верификация – процесс определения соответствия программного обеспечения предназначению.
Аттестация – процесс подтверждения функциональной пригодности программного обеспечения.
Валидация — это проверка того, что сам продукт правилен, т.е. подтверждение того, что он действительно удовлетворяет потребностям и ожиданиям пользователей, заказчиков и других заинтересованных сторон.
Стандартизация выполняет следующие функции:
-
упорядочивание объектов (продукции, работ, услуг, процессов), создаваемых людьми в разных странах;
-
закрепление в нормативных документах оптимальных требований к упорядоченным объектам;
-
установление правил применения этих нормативных документов.
На международном уровне стандартизация:
-
обеспечивает взаимозаменяемость элементов сложной продукции;
-
сближает уровень качества товаров, производимых в разных странах;
-
содействует взаимообмену научно-технической информацией;
-
содействует международной торговле.
-
ускоряет научно-технический прогресс участников международных организаций.
Дополнительная информация:
Для каждого процесса требуется иметь планы развития процесса, состоящие как минимум из следующих разделов:
-
Проектирование процесса.
-
Документирование процесса.
-
Реализация процесса.
-
Поддержка процесса.
-
Мониторинг процесса.
-
Управление процессом.
-
Усовершенствование процесса.
Проектирование
Этапы и результаты проектирования:
-
Описание: совместная работа заказчика (говорит о пользе продукта, требованиях к работоспособности и внешнему виду) и EDISON (предлагает технические и алгоритмические решения).
-
Архитектура: утверждается язык программирования, база данных, серверы и фреймворки.
-
Техническое задание: составляется архитектором на основании описания и ответов заказчика на вопросы, согласовывается с менеджером проекта, затем передается клиенту, производятся правки.
-
Макеты (добавляются к техзаданию): интерфейсов, принципиальные схемы устройства, диаграммы структуры базы данных, схемы взаимодействия компонентов.
-
Контроль: архитектор устраняет замечания менеджера проектов.
-
Утверждение: заказчик проверяет и меняет ТЗ самостоятельно или сообщает список правок проект-менеджеру, замечания устраняются, ТЗ утверждается и прилагается к контракту.
Проектируя ПО заранее, разработчик получает возможность:
-
оценить стоимость и время разработки программного продукта,
-
исключить потери времени и денег на ненужные действия, вынужденные доработки, длительное согласование,
-
избежать разногласий и неудовлетворённости клиента и исполнителя.
Минимально достаточное ТЗ должно:
-
полностью, чётко (без воды, возможности разночтения) и структурировано описывать будущий программный продукт (как должен выглядеть, как и с чем работать, каким требованиям отвечать) и процесс его разработки, чтобы у архитектора не возникало вопросов по реализации,
-
исключать противоречивые сведения,
-
быть юридически точным (следовать ГОСТ 34.602-89), поскольку вместе с контрактом и прочими документами ТЗ приобретает юридическую силу.
Техническое задание должно содержать:
-
общие данные о проекте (название продукта, кем и для чего будет использоваться);
-
общие требования к ПО (к структуре, функциям, в частности приложить схему архитектуры и описать связь подсистем, виды интерфейсов всех составляющих для каждой из ролей пользователей — готовый дизайн или его концепцию);
-
подробный план работ (перечень этапов, сроки по ним);
-
порядок тестирования и приемки (виды и состав испытаний продукта в целом и отдельных частей);
-
перечень действий для запуска продукта;
-
требования к документированию процесса и результата разработки.
Документирование
Существует четыре основных типа документации на ПО:
-
архитектурная/проектная — обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть использованы при создании ПО
-
техническая — документация на код, алгоритмы, интерфейсы, API
-
пользовательская — руководства для конечных пользователей, администраторов системы и другого персонала
-
маркетинговая
Архитектурная/проектная документация
Проектная документация обычно описывает продукт в общих чертах. Не описывая того, как что-либо будет использоваться, она скорее отвечает на вопрос «почему именно так?» Например, в проектном документе программист может описать обоснование того, почему структуры данных организованы именно таким образом. Описываются причины, почему какой-либо класс сконструирован определённым образом, выделяются паттерны, в некоторых случаях даже даются идеи как можно будет выполнить улучшения в дальнейшем. Ничего из этого не входит в техническую или пользовательскую документацию, но всё это действительно важно для проекта.
Техническая документация
Это именно то, что подразумевают под термином документация большинство программистов. При создании программы, одного лишь кода, как правило, недостаточно. Должен быть предоставлен некоторый текст, описывающий различные аспекты того, что именно делает код. Такая документация часто включается непосредственно в исходный код или предоставляется вместе с ним.
Подобная документация имеет сильно выраженный технических характер и в основном используется для определения и описания API, структур данных и алгоритмов.
Часто при составлении технической документации используются автоматизированные средства — генераторы документации. Они получают информацию из специальным образом оформленных комментариев в исходном коде, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML. Использование генераторов документации и документирующих комментариев многими программистами признаётся удобным средством, по различным причинам. В частности, при таком подходе документация является частью исходного кода, и одни и те же инструменты могут использоваться для сборки программы и одновременной сборки документации к ней. Это также упрощает поддержку документации в актуальном состоянии.
Пользовательская документация
В отличие от технической документации, сфокусированной на коде и том как он работает, пользовательская документация описывает лишь то, как использовать программу.
В случае, если продуктом является программная библиотека, пользовательская документация и документация на код становятся очень близкими, почти эквивалентными понятиями. Но в общем случае, это не так.
Обычно, пользовательская документация представляет из себя руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская документация идёт ещё дальше и предоставляет инструкции о том, что делать в случае возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение.
Существует три подхода к организации пользовательской документации. Вводное руководство (англ. tutorial), наиболее полезное для новых пользователей, последовательно проводит по ряду шагов, служащих для выполнения каких-либо типичных задач. Тематический подход, при котором каждая глава руководства посвящена какой-то отдельной теме, больше подходит для совершенствующихся пользователей. В последнем, третьем подходе, команды или задачи организованы в виде алфавитного справочника — часто это хорошо воспринимается продвинутыми пользователями, хорошо знающими, что они ищут. Жалобы пользователей обычно относятся к тому, что документация охватывает только один из этих подходов, и поэтому хорошо подходит лишь для одного класса пользователей.
Во многих случаях разработчики программного продукта ограничивают набор пользовательской документации лишь встроенной системой помощи, содержащей справочную информацию о командах или пунктах меню. Работа по обучению новых пользователей и поддержке совершенствующихся пользователей перекладывается на частных издателей, часто оказывающих значительную помощь разработчикам.
Маркетинговая документация
Для многих приложений необходимо располагать рядом рекламных материалов, с тем чтобы заинтересовать людей, обратив их внимание на продукт. Такая форма документации имеет целью:
-
подогреть интерес к продукту у потенциальных пользователей
-
информировать их о том, что именно делает продукт, с тем чтобы их ожидания совпадали с тем что они получат
-
объяснить положение продукта по сравнению с конкурирующими решениями
Одна из хороших маркетинговых практик — предоставление слогана — простой запоминающейся фразы, иллюстрирующей то что мы хотим донести до пользователя, а также характеризующей ощущение, которое создаёт продукт.
Часто бывает так, что коробка продукта и другие маркетинговые материалы дают более ясную картину о возможностях и способах использования программы, чем всё остальное.