К какой категории профилей относится обеспечение качества программных средств
Перейти к содержимому

К какой категории профилей относится обеспечение качества программных средств

  • автор:

К какой категории профилей относится обеспечение качества программных средств

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

4.1. Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства.

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

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

Внешнее описание ПС играет роль точной постановки задачи, решение которой должно обеспечить разрабатываемое ПС. Более того, оно должно содержать всю информацию, которую необходимо знать пользователю для применения ПС. Оно является исходным документом для трех параллельно протекающих процессов: разработки текстов ( к iinoрoeрiaaie ? и кодированию) программ, входящих в ПС, разработки документации по применению ПС и разработки существенной части комплекта тестов для тестирования ПС. Ошибки и неточности во внешнем описании, в конечном счете, трансформируются в ошибки самой ПС и обходятся особенно дорого, во-первых, потому, что они делаются на самом раннем этапе разработки ПС, и, во-вторых, потому, что они распространяются на три параллельных процесса. Это требует особенно серьезных мер по их предупреждению.

Исходным документом для разработки внешнего описания ПС являются определение требований к ПС. Но так как через этот документ передается от заказчика (пользователя) к разработчику основная информация относительно требуемого ПС, то формирование этого документа представляет собой довольно длительный и трудный итерационный процесс взаимодействия между заказчиком и разработчиком, с которого и начинается этап разработки требований к ПС [4.2]. Трудности, возникающие в этом процессе, связаны с тем, что пользователи часто плохо представляют, что им на самом деле нужно: использование компьютера в «узких» местах деятельности пользователей может на самом деле потребовать принципиального изменения всей технологии этой деятельности (о чем пользователи, как правило, и не догадываются). Кроме того, проблемы, которые необходимо отразить в определении требований, могут не иметь определенной формулировки [4.1], что приводит к постепенному изменению понимания разработчиками этих проблем. В связи с этим определению требований часто предшествует процесс системного анализа, в котором выясняется, насколько целесообразно и реализуемо «заказываемое» ПС, как повлияет такое ПС на деятельность пользователей и какими особенностями оно должно обладать. Иногда для прояснения действительных потребностей пользователей приходится разрабатывать упрощенную версию требуемого ПС, называемую прототипом ПС. Анализ «пробного» применения прототипа позволяет иногда существенно уточнить требования к ПС.

В определении внешнего описания легко бросаются в глаза две самостоятельные его части. Описание поведения ПС определяет функции, которые должна выполнять ПС, и потому его называют функциональной спецификацией ПС. Функциональная спецификация определяет допустимые фрагменты программ, реализующих декларированные функции. Требования к качеству ПС должны быть сформулированы так, чтобы разработчику были ясны цели [4.2], которые он должен стремиться достигнуть при разработке этого ПС. Эту часть внешнего описания будем называть спецификацией качества ПС (в литературе ее часто называют нефункциональной спецификацией [4.1], но она, как правило, включает и требования к технологическим процессам). Она, в отличие от функциональной спецификации, реализуется неформализованно и играет роль тех ориентиров, которые в значительной степени определяют выбор подходящих альтернатив при реализации функций ПС, а также определяет стиль всех документов и программ разрабатываемого ПС. Тем самым, спецификация качества играет решающую роль в обеспечении требуемого качества ПС.

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

Внешнее описание ПС = спецификация качества ПС + функциональная спецификация ПС

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

4.2. Спецификация качества программного средства.

Разработка спецификации качества сводится, по-существу , к построению своеобразной модели качества разрабатываемой ПС [4.2, 4.3]. В этой модели должен быть перечень всех тех достаточно элементарных свойств, которые требуется обеспечить в разрабатываемом ПС и которые в совокупности образуют приемлемое для пользователя качество ПС. При этом каждое из этих свойств должно быть в достаточной степени конкретизировано с учетом определения требований к разрабатываемому ПС и возможности оценки его наличия у разработанного ПС или необходимой степени обладания им этим ПС.

Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств ПС [4.3-4.6], однозначно интерпретируемых разработчиками. Такие свойства мы будем называть примитивами качества ПС. Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от примитивов качества ПС.

Функциональность: завершенность.

Надежность: завершенность, точность, автономность, устойчивость, защищенность.

Легкость применения: П-документированность , информативность (только применительно к документации по применению), коммуникабельность, устойчивость, защищенность.

Эффективность: временн a я эффективность, эффективность по памяти, эффективность по устройствам.

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

Изучаемость : С-документированность, информативность (здесь применительно и к документации по сопровождению), понятность, структурированность, удобочитаемость.

Модифицируемость: расширяемость, структурированность, модульность.

Мобильность: независимость от устройств, автономность, структурированность, модульность.

Ниже даются определения используемых примитивов качества ПС [4.3-4.5].

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

Точность — мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.

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

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

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

П-документированность — свойство, характеризующее наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и справочной документации, необходимой для применения ПС.

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

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

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

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

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

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

Понятность — свойство, характеризующее степень в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких примитивов ИСО [4.4], как согласованность, самодокументированность , четкость и, собственно, понятность.

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

Удобочитаемость — свойство, характеризующее легкость восприятия текста программ ПС (отступы, фрагментация, форматив-

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

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

Независимость от устройств — свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях ЭВМ).

4.3. Функциональная спецификация программного средства.

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

Функциональная спецификация состоит из трех частей:

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

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

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

В третьей части должны быть перечислены все существенные с точки зрения внешнего наблюдателя (пользователя) случаи, когда ПС не сможет нормально выполнить ту или иную свою функцию (например, при обнаружении ошибки во время взаимодействия с пользователем, или при попытке применить какую-либо функцию к данным, не удовлетворяющим соотношениям, указанным в ее спецификации, или при получении результата, нарушающего заданное ограничение). Для каждого такого случая должна быть определена (описана) реакция ПС.

4.5. Методы контроля внешнего описания программного средства.

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

  • статический просмотр,
  • смежный контроль,
  • пользовательский контроль,
  • ручная имитация.

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

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

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

Ручная имитация выражает своеобразный динамический контроль внешнего описания, точнее говоря, функциональной спецификации ПС. Для этого необходимо подготовить исходные данные (тесты) и на основании функциональной спецификации осуществить имитацию поведения (работы) разрабатываемого ПС. При этом эту имитацию осуществляет специально назначенный разработчик, выполняющий, по-существу , роль будущих программ ПС. Разновидностью такого контроля является имитация за терминалом. В этом случае данные вводятся в компьютер человеком, играющего роль пользователя, и передаются с помощью несложной программы на другой терминал, за которым сидит разработчик, выполняющий роль программ ПС. Полученные результаты передаются через компьютер на первый терминал.

Литература к лекции 4.

4.1. Ian Sommerville . Software Engineering. — Addison-Wesley Publishing Company, 1992. — P.

4.2. Г. Майерс . Надежность программного обеспечения. — М.: Мир, 1980. — С. 49-77.

4.3. Е.А. Жоголев . Введение в технологию программирования (конспект лекций). — М.: «ДИАЛОГ-МГУ», 1994.

4.4. Criteria for Evaluation of Software. ISO TC97/SC7 #383.

4.5. Revised version of DP9126 — Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. — Part 6.

4.6. Б . Боэм , Дж . Браун , Х . Каспар и др . Характеристики качества программного обеспечения. — М.: Мир, 1981. — С. 61-87.

К какой категории профилей относится обеспечение качества программных средств

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

характеристика
оценка качества
программные средства

1. Баранюк В.В., Тютюнников Н.Н. Оценка качества электронных словарей и энциклопедий // Программная инженерия. – 2012. – № 8. – С. 29–37.

2. Гличев А.В., Панов В.П., Азгальдов Г.Г. Что такое качество? – М.: Экономика, 1968. 135 с.

3. Горбаченко И.М. Программное обеспечение для создания автоматизированных обучающих систем // Проблемы информатизации региона. ПИР-2005: материалы девятой научно-практической конференции (Красноярск, 11–12 окт. 2005 г.). – Красноярск: ИПЦ КГТУ, 2005. – т. 2. – С. 132–135.

4. Горбаченко И.М. Сравнительный анализ существующих систем тестирования // Тестирование в сфере образования: проблемы и перспективы развития: материалы Всероссийской научно-практической конференции. (Красноярск, 19-21 мая 2008 г.) / отв. ред. Г.П. Карлов. – Красноярск: СибГТУ, 2008. – С. 177–183.

5. Липаев В.В. Проблемы обеспечения качества сложных программных средств [Электронный ресурс]. – Режим доступа: http://quality.eup.ru/MATERIALY4/poksps.htm (дата обращения 9.04.2013).

6. Лозинин А.И., Шубинский И.Б. Характеристики качества программного обеспечения и методы их оценки [Электронный ресурс]. – Режим доступа: http://www.ibtrans.ru/Estimating %20methods.pdf (дата обращения 12.03.2013).

На современных компьютерах установлено множество разнообразного программного обеспечения (ПО). И хочется, чтобы оно было качественное, работоспособное, работало без сбоев и т.д. [1, 2, 5] Рассмотрим определение «качества ПО» (Software Quality) в контексте международных стандартов:

1) качество программного обеспечения – это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. [1061-1998 IEEE Standard for Software Quality Metrics Methodology];

2) качество программного средства – совокупность свойств программного средства (ПС), которые обусловливают его пригодность удовлетворять заданные или подразумеваемые потребности в соответствии с его назначением [ГОСТ 28806–90 «Качество программных средств. Термины и определения»].

Целью данной работы является разработка методики применения требований стандарта ISO 9126 к оценке качества одного из видов программных средств – систем создания тестов.

Стандарт ISO 9126

На данный момент наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. Основой регламентирования показателей качества систем является международный стандарт ISO 9126 «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». В этом стандарте описано многоуровневое распределение характеристик ПО. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки (рисунок) [1, 2].

Согласно этой модели, функциональность программного средства (functionality) – совокупность свойств ПС, определяемая наличием и конкретными особенностями набора функций, способных удовлетворять заданные или подразумеваемые потребности качества наряду с ее надежностью как технической системы. Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Удобство использования программного средства (usability) – совокупность свойств ПС, характеризующая усилия, необходимые для его использования, и оценку результатов его использования заданным кругом пользователей ПС. Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности в соответствии с выделенными ресурсами, временем и другими обозначенными условиями. Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов, для реализации новых требований, для облегчения дальнейшего обслуживания и адаптироваться к именующемуся окружению. Портативность (Portability) – совокупность свойств ПС, характеризующая приспособленность для переноса из одной среды функционирования в другие.

pic_8.tif

Модель качества программного обеспечения (ISO 9126)

Программное обеспечение для создания систем тестирования

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

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

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

В настоящее время все чаще стали появляться готовые средства для разработки обучающих программ [3, 4, 5, 6]. Причем эти разработки не только зарубежных (для примера – Adobe Acrobat, Macromedia Authorware, ToolBook II, Quest и другие), но и отечественные (например, HyperMethod, «Доцент», «Прометей», сетевая оболочка «ОРОКС», КАДИС). Приведем краткую характеристику некоторых из них.

Одина из систем для проведения тестирования «Конструктор тестов» – универсальная система проверки знаний (сайт системы – http://www.keepsoft.ru/simulator.htm). Программа поддерживает пять типов вопросов: закрытые (на выбор одного или нескольких ответов), открытый (ввод ответа), на соответствие и на упорядочивание. Это позволяет проводить любые тесты. В тестах имеется возможность использовать музыку, звуки, изображения и видеоролики. Любые данные можно распечатать на принтере. На одном компьютере тестирование независимо могут проходить несколько человек, входя в программу под своими именами.

Следующий пакет – система тестирования INDIGO (сайт – http://indigotech.ru/). В этой системе также можно создавать тестовые задания 5 типов. Но кроме этого особенностью конструктора тестов INDIGO является поддержка многоуровневой иерархической группировки вопросов тестов по заданиям, темам и т.д. Ведь если вопросы теста отображаются в одном линейном списке, то возникают сложности с навигацией и пониманием того, какой вопрос к чему относится. В этой системе имеется возможность задания для каждой группы индивидуальных настроек (в особенности, порядка выдачи вложенных элементов или их случайной выборки).

Следующий рассматриваемый пакет – VeralTest – комплекс программ для создания тестовых задний и для организации многопользовательского компьютерного тестирования (сайт – http://veralsoft.com/veraltest.shtml). В этой системе могут быть созданы следующие типы тестовых задний – закрытый (выбор одного ответа и выбор нескольких ответов), ввод текстового ответа, ввод числового ответа, вопросы на соответствие.

Пакет программ VeralTest представлен в двух редакциях:

– VeralTest Express. Позволяет создавать автономные самозапускамые тесты (exe тесты), которые могут быть запущены на любом компьютере без предварительной установки и настройки. Состав пакета VeraTest Express: редактор тестов TestEditor и программа для просмотра результатов тестирования ResultViewer.

– VeralTest Professional. Поддерживает все функции express редакции. Кроме этого, в состав пакета входит сервер тестирования (программа TestServer), позволяющий организовать тестирование в компьютерном классе или локальной сети предприятия. При этом доступ к тестам осуществляется через веб-браузер (например, Internet Explorer, Google Chrome, Mozila Firefox). Еще эта редакция включает в себя программу администрирования TestAdmin, при помощи которой можно регистрировать пользователей, объединять их в группы, назначать тесты для выполнения пользователями, просматривать и распечатывать результаты тестирования.

Кроме указанных программных комплексов, существует множество других систем [3, 4, 5]. С некоторыми из них можно познакомиться на сайте – http://edu.of.ru/volsch31/default.asp?ob_no = 2300.

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

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

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

Если за наличие каждого признака ставить 1 балл, то получается что из рассматриваемых систем MOODLE получила 22 балла, UniTest System – 15, «Конструктор тестов» – 11, INDIGO – 14, VeralTest – 12 (версия Express) и 16 (версия Professional).

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

Оценка показателей качества программных средств может осуществляться различными методами и способами [3, 4, 5, 6]. Представленная в статье методика оценки качества, основанная на принципах стандарта ISO 9126, позволяет:

– оценить качество программных комплексов, используя различные системы показателей качества;

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

Сравнительные характеристики некоторых средств для создания обучающих курсов

2.3. ПРОФИЛИ СТАНДАРТОВ

При создании сложных тиражируемых ПС целесообразно формирование и применение совокупностей стандартов и нормативных документов. Такие совокупности должны адаптироваться к классам проектов и процессов. Профиль стандартов – это совокупность нескольких базовых стандартов и/или других нормативных документов с четко определенными и гармонизированными подмножествами обязательных и дополнительных возможностей, предназначенная для реализации заданной функции или группы функций. Исходной для формирования и применения профиля стандартов системы (ПС) или процесса является их функциональная характеристика (набор функций). На базе одной и той же совокупности стандартов могут формироваться различные профили для разных проектов ПС (за счет, например, различных выбранных значений параметров стандарта или различных выбранных положений стандарта) [4]. В международной стандартизации ПО принято, что основой профиля могут быть только международные и национальные утвержденные стандарты (не допускается использование неутвержденных стандартов и нормативных документов фирм). В качестве методологической основы построения и применения профилей сложных, распределенных систем рекомендуется использовать технический отчет ISO/IEC TR 10000 . В этом стандарте определена эталонная модель среды открытых систем (OSE/RM). Она определяет разделение любой информационной среды на приложения (прикладные программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой определяются стандартизированные интерфейсы (Application Program Interface – API). Эти интерфейсы являются необходимой частью профилей любой открытой системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия прикладных программ (функциональных частей) между собой и интерфейсы взаимодействия между компонентами среды ИС. Спецификации выполняемых функций и интерфейсов взаимодействия могут быть оформлены как профиль каждого компонента системы. Различают следующие категории профилей стандартов : • профили конкретного ПС; действуют в пределах проекта и являются частью проектной документации;

19 • профили для решения некоторого класса прикладных задач; распространяются на все ПС данного класса, утверждаются как стандарты предприятий, ведомственные или государственные стандарты. В ЖЦ ПС выделяется две группы профилей : • профили, регламентирующие архитектуру и структуру ПС и их компонентов (функции, интерфейсы, протоколы взаимодействия, форматы данных и т.п.); • профили, регламентирующие процессы и системы обеспечения качества проектирования, разработки, применения, сопровождения и развития ПС и их компонентов. Качество ИС тесно связано с методами и технологией их разработки. Поэтому важной группой документов в профилях являются стандарты, связанные с непосредственным обеспечением и системой качества ЖЦ ПС. 2.4. ПРОФИЛЬ СИСТЕМЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ Система качества – совокупность организационных структур, методик, технологий и ресурсов, необходимых для осуществления общего руководства качеством. Она должна быть составной частью системы управления организации и должна создавать у руководства организации и у потребителя (заказчика) уверенность в том, что ПС будет соответствовать установленным требованиям к его качеству. Профиль системы качества предприятия или проекта зависит от профиля ЖЦ ПС. Профиль ЖЦ ПС определяет этапы создания, сопровождения и развития ПС, все основные и поддерживающие процессы, выполняемые на протяжении ЖЦ (в том числе и процессы системы качества). В связи с возрастающей ролью качества сложных ПС следует выделять профиль системы обеспечения качества ПС конкретного предприятия или проекта, регламентирующий требования к качеству и меры по его обеспечению (рис.3) [4]. Стандарты, важные с точки зрения заказчика, должны задаваться в техническом задании (ТЗ) и контракте на проектирование ПС и составлять его первичный профиль . В дальнейшем разработчик может дополнять первичный профиль, согласовывая его с заказчиком. При формировании профилей стандартов, обеспечивающих качество ЖЦ конкретных ПС допустимо использовать как международные и национальные стандарты, так и ведомственные нормативные документы, и неутвержденные стандарты (де-факто).

20 Показатели качества ПС – ISO 9126 Жизненный цикл ПС – ISO 12207 Административное управление и обеспечение качества ПС – ISO 9000-3 Руководство по обеспечению качества – ISO 10013 Программа обеспечения качества – ISO 10005 Руководство по управлению конфигурацией – ISO 10007, ISO 15846 Руководство по проверке (сертификации) систем качества – ISO 10011 Стандарты по защите и обеспечению безопасности применения ПС Стандарты по документированию ПС Методические руководства по выполнению основных этапов ЖЦ ПС Рабочие инструкции конкретным исполнителям этапов ЖЦ ПС Рабочие инструкции специалистам системы обеспечения качества ПС Рис.3. Профиль стандартов, обеспечивающих качество ЖЦ ПС

21 ТЕМА 3. СТАНДАРТИЗАЦИЯ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В РЕСПУБЛИКЕ БЕЛАРУСЬ 3.1. ОБЩИЕ СВЕДЕНИЯ О СТАНДАРТАХ В ОБЛАСТИ ОЦЕНКИ КАЧЕСТВА, ДЕЙСТВУЮЩИХ НА ТЕРРИТОРИИ РБ В настоящее время в области обеспечения качества ПО на территории Республики Беларусь действуют следующие основные стандарты: ГОСТ 28806-90 – Качество программных средств. Термины и определения; ГОСТ 28195-99 – Оценка качества программных средств. Общие положения; СТБ ИСО/МЭК 9126-2003 – Информационные технологии. Оценка программной продукции. Характеристики качества и руководства по их применению [8, 7, 12]. Стандарт СТБ ИСО/МЭК 9126-2003 представляет собой аутентичный перевод международного стандарта ISO/IEC 9126:91 [28] . Данный стандарт под номером ГОСТ Р ИСО/МЭК 9126-93 действует на территории России с 1994 года [10]. Обеспечение качества неразрывно связано с жизненным циклом ПС. ЖЦ ПС регламентирован стандартом СТБ ИСО/МЭК 12207-2003 – Процессы жизненного цикла программных средств [11]. При именовании стандартов используются следующие обозначения : − вначале записывается категория стандарта (СТБ – стандарт Беларуси, ГОСТ Р – государственный стандарт России, ГОСТ – межгосударственный стандарт для ряда стран СНГ, до распада СССР аббревиатура ГОСТ обозначала государственный стандарт СССР); − если стандарт разработан методом прямого применения (является аутентичным переводом) международного стандарта, то за категорией стандарта следует обозначение категории данного международного стандарта (в русском именовании); например, СТБ ИСО/МЭК и ГОСТ Р ИСО/МЭК – это аутентичные переводы международного стандарта ISO/IEC; − затем следует номер стандарта; при этом, если стандарт разработан методом прямого применения, то его номер совпадает с номером международного стандарта; например, СТБ ИСО/МЭК 9126, ГОСТ Р ИСО/МЭК 9126, ISO/IEC 9126; − после номера стандарта через дефис записывается год его утверждения СТБ ИСО/МЭК 9126-2003, ГОСТ Р ИСО/МЭК 9126-93. Обозначения международных стандартов описаны в разд. 4. В стандарте ГОСТ 28806-90 регламентируются основные термины и

22 определения, принятые в области обеспечения качества ПО. Данные термины приведены в подразд. 1.1 . Стандарт ГОСТ 28195-99 определяет оценку качества программного средства как совокупность операций, включающих выбор номенклатуры характеристик качества оцениваемого программного средства, определение значений этих характеристик и сравнение их с базовыми значениями. Оценка качества должна проводиться применительно ко всем работам ЖЦ ПС при: 1) планировании характеристик качества ПС; 2) контроле качества в процессе разработки; 3) проверке эффективности модификации ПС в процессе сопровождения. Основные задачи , решаемые при оценке качества программного средства: 1) планирование номенклатуры характеристик и показателей качества; 2) планирование уровня качества; 3) выбор методов контроля показателей качества; 4) контроль значений показателей качества в процессе жизненного цикла ПС; 5) выбор базовых образов по подклассам и группам; 6) принятие решения о соответствии реальных значений показателей качества установленным требованиям. 3.2. КЛАССИФИКАЦИЯ МЕТОДОВ ОПРЕДЕЛЕНИЯ ПОКАЗАТЕЛЕЙ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА ГОСТ 28195-99 классифицирует методы определения показателей качества ПС, исходя из следующих факторов : • по способам получения информации о показателе качества: а) измерительный; б) регистрационный; в) органолептический; г) расчетный; • по источникам получения информации о показателе качества: а) экспертный; б) социологический; в) традиционный. Измерительный метод определения показателей качества ПС – это метод получения информации о свойствах и характеристиках ПС путем измерений с помощью инструментальных средств (например, так может определяться количество операторов в программе, количество выполненных операторов, количество операндов, время выполнения программы при определенных наборах исходных данных и т.д.). Регистрационный метод определения показателей качества ПС – это

23 метод получения информации о свойствах и характеристиках ПС во время его испытания или функционирования, когда регистрируются определенные события (например, количество сбоев и отказов). Органолептический метод определения показателей качества ПС – это метод получения информации о свойствах и характеристиках ПС, основанный на восприятии органов чувств (зрения и слуха) человека. Так может определяться, например, удобство использования. Расчетный метод определения показателей качества ПС – это метод получения информации о свойствах и характеристиках ПС, основанный на использовании эмпирических и теоретических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. Так может определяться, например, точность вычислений. Экспертный метод определения показателей качества ПС – это метод получения информации о свойствах и характеристиках ПС на основании мнений группы экспертов-специалистов, компетентных в решении данной задачи на базе их опыта и интуиции. Экспертный метод применяется, когда невозможно или слишком трудоемко выполнить оценку показателей качества с помощью других методов. С помощью данного метода рекомендуется определять, например, показатели понимаемости и осваиваемости ПС. Социологический метод определения показателей качества ПС – это метод получения информации о свойствах и характеристиках ПС на основании обработки специальных анкет-опросников. Так могут определяться, например, отдельные показатели удобства использования. Социологический метод определен в предыдущей версии ГОСТ 28195-99 (ГОСТ 28195-89 [6]). Традиционный метод определения показателей качества ПС – это метод получения информации о свойствах и характеристиках ПС на основании непосредственного наблюдения за их функционированием в процессе работы. Так могут определяться, например, некоторые из показателей функциональности и удобства использования. 3.3. ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ОЦЕНКИ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА Стандарты ГОСТ 28806-90, ГОСТ 28195-99, СТБ ИСО/МЭК 9126-2003 регламентируют выполнение оценки качества ПС и систем на основе иерархической модели качества . В соответствии с данной моделью совокупность свойств, отражающих качество программного средства, представляется в виде многоуровневой структуры. Характеристики на первом (верхнем) уровне соответствуют основным свойствам ПС. Характеристики (подхарактеристики) каждого уровня оцениваются посредством характеристик (подхарактеристик) последующих уровней. Стандарты ГОСТ 28806-90, СТБ ИСО/МЭК 9126-2003 определяют первые

24 два уровня иерархической модели качества. При этом номенклатура характеристик первого уровня является обязательной , а номенклатура характеристик второго уровня (подхарактеристик) – рекомендуемой . Стандарт ГОСТ 28195-99 определяет четырехуровневую иерархическую модель оценки качества ПС. Номенклатура характеристик и подхарактеристик первых двух уровней является обязательной , а номенклатура подхарактеристик третьего и четвертого уровней – рекомендуемой. Вышеназванные стандарты определяют шесть основных характеристик качества ПС, находящихся на верхнем уровне модели качества. Следует отметить, что характеристики верхнего уровня, регламентированные в ГОСТ 28806-90 и СТБ ИСО/МЭК 9126-2003, соответствуют принятым в настоящее время в мировой практике. В то же время характеристики и подхарактеристики, определенные в ГОСТ 28195-99, частично не соответствуют иерархической модели качества, принятой в международных стандартах. В стандартах ГОСТ 28806-90 и СТБ ИСО/МЭК 9126-2003 определены следующие основные характеристики качества программных средств (характеристики качества первого уровня; в скобках приведены англоязычные эквиваленты терминов): 1. Функциональность (Functionality) . Совокупность свойств программного средства, определяемая наличием и конкретными особенностями набора функций, способных удовлетворять заданные или подразумеваемые потребности. 2. Надежность (Reliability) . Совокупность свойств, характеризующая способность программного средства сохранять заданный уровень пригодности в заданных условиях в течение заданного интервала времени. 3. Удобство использования (практичность, Usability). Совокупность свойств программного средства, характеризующая усилия, необходимые для его использования, и индивидуальную оценку результатов его использования заданным или подразумеваемым кругом пользователей. 4. Эффективность (Efficiency) . Совокупность свойств программного средства, характеризующая те аспекты его уровня пригодности, которые связаны с характером и временем использования ресурсов, необходимых при заданных условиях функционирования. 5. Сопровождаемость (Maintainability) . Совокупность свойств программного средства, характеризующая усилия, которые необходимы для его модификации. 6. Мобильность (Portability) . Совокупность свойств программного средства, характеризующая приспособленность для переноса из одной среды функционирования в другие.

25 3.4. ЭКОНОМИЧЕСКИЙ МЕТОД ИНТЕГРАЛЬНОЙ ОЦЕНКИ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ Существуют различные методы интегральной оценки качества программных средств. Данные методы позволяют получить итоговую интегральную величину качества ПС в целом или его отдельных характеристик, выраженную в некоторых количественных единицах. В данном и следующем подразделах рассмотрено два метода интегральной оценки качества программных средств. Экономический метод интегральной оценки качества ПС относится к группе расчетных методов (см. подразд. 3.2). В соответствии с данным методом формулируется количественный критерий качества ПС, ориентированный на весь его жизненный цикл длиной Т . В качестве такого критерия предлагается минимизация суммарных затрат живого и овеществленного труда на разработку, эксплуатацию и сопровождение ПС . Данные затраты складываются из следующих компонентов . К1 – единовременные (в течение ЖЦ ПС) затраты Z на разработку ПС: К1=Z. К2 – единовременные затраты W на внедрение ПС: K2 = W. К3 – систематические затраты S на эксплуатацию ПС, регулярно повторяющиеся в течение жизненного цикла T через период времени tэ : К3 = (Т/tэ) * S. К4 – спорадические (повторяющиеся через случайные промежутки времени) затраты на сопровождение, которые составляют в среднем n -ую часть от затрат Z и m -ую часть от затрат W и осуществляются в течение жизненного цикла T в среднем через периоды времени tс : К4 = (n*Z+ m*W)*Т/tс. К5 – случайные потери из-за недостоверности или несвоевременности результата: К5 = Sп *Т/tэ. Здесь Sп – средняя сумма потерь, приходящаяся на однократную эксплуатацию ПС в течение его ЖЦ. Итоговая формула оптимизации качества ПС в течение его ЖЦ выглядит следующим образом: Z + W + (Sп + S) * Т/tэ + (n*Z + m*W) * Т/tс→min. Критерием качества ПС служит степень близости фактического значения вышеприведенного выражения к его минимуму.

26 Основным недостатком данного метода является то, что компоненты К1 — К5 не могут служить основой построения системы управления качеством ПС в процессе его разработки с целью достижения заданного уровня качества. 3.5. МЕТОД ОЦЕНКИ КАЧЕСТВА, ОСНОВАННЫЙ НА ИЕРАРХИЧЕСКОЙ МОДЕЛИ Стандартом ГОСТ 28195-99 рекомендован метод интегральной оценки качества ПС, основанный на иерархической модели качества. В соответствии с данным методом выбор номенклатуры показателей качества для конкретного программного средства осуществляется с учетом его назначения и требований областей применения в зависимости от принадлежности ПС к тому или иному подклассу, определяемому общесоюзным классификатором продукции (ОКП) . В ОКП предусмотрены следующие подклассы ПС : − 5011 – операционные системы и средства их расширения; − 5012 – программные средства управления базами данных;

− 5013 – инструментально-технологические средства
программирования;

− 5014 – ПС интерфейса и управления коммуникациями; − 5015 – ПС организации вычислительного процесса (планирования, контроля); − 5016 – сервисные программы; − 5017 – ПС обслуживания вычислительной техники; − 503 – прикладные программы для научных исследований; − 504 – прикладные программы для проектирования; − 505 – прикладные программы для управления техническими устройствами и технологическими процессами; − 506 – прикладные программы для решения экономических задач; − 509 – прочие ПС. Оценка качества ПС производится на всех фазах жизненного цикла. Стандарт ГОСТ 28195-99 базируется на следующих процессах и фазах жизненного цикла ПС : 1 Процесс разработки: • фаза анализа; • фаза проектирования; • фаза реализации; • фаза тестирования; • фаза изготовления. 2 Процесс применения: • фаза внедрения; • фаза эксплуатации;

27 • фаза сопровождения. Понятие фазы жизненного цикла (ЖЦ), используемое в описываемом методе, в настоящее время является устаревшим. Современная интерпретация жизненного цикла ПС, регламентированная стандартом СТБ ИСО/МЭК 122072003 [11] , представляет ЖЦ ПС в виде совокупности процессов, работ и задач, организованных в иерархическую структуру. Подробное описание ЖЦ ПС приведено в подразд.6.2. Из вышеприведенного перечня фаз следует, что устаревшее понятие фазы ЖЦ для процесса разработки наиболее близко по смыслу современному понятию работы ЖЦ (и, по сути, представляет собой одну или объединение нескольких работ), а для процесса применения – понятиям работы и процесса. В этой связи рекомендованный стандартом ГОСТ 28195-99 метод интегральной оценки качества ПС после соответствующей адаптации может применяться и при современной интерпретации ЖЦ ПС. Оценка качества ПС заключается в выборе номенклатуры показателей, их оценке и сопоставлении с базовыми значениями. Основу описываемого метода оценки качества составляет четырехуровневая иерархическая модель качества. ГОСТ 28195-99 предлагает свою терминологию для показателей качества каждого уровня: уровень 1 — факторы качества (в терминологии, принятой в современных международных стандартах, соответствуют характеристикам качества [28, 10, 12, 24]); уровень 2 — критерии качества (в современной терминологии – подхарактеристики качества); уровень 3 — метрики (соответствует современной терминологии); уровень 4 — оценочные элементы или единичные показатели (в современной терминологии – свойства или атрибуты ПС). Для каждой из выбранных характеристик качества составляется четырехуровневая иерархическая модель, отражающая взаимосвязь факторов, критериев, метрик и оценочных элементов. Вид данной модели зависит от фазы ЖЦ. В качестве примера на рис.4 – рис.6 приведены три верхних уровня иерархической модели характеристики Надежность для различных фаз ЖЦ. Номера на данных рисунках соответствуют номерам метрик характеристики Надежность. Выбор оценочных элементов в метрике зависит от функционального назначения ПС и формируется с учетом данных, ранее полученных при проведении испытаний ПС и эксплуатации аналогичных программ. Для выбора оценочных элементов ГОСТ 28195-99 предлагает перечень таблиц, содержащих наименование элемента, метод оценки и применяемость элемента для различных подклассов ПС.

Фактор Критерий Метрика
1 Средства
Надежность Устойчивость восстановления при
функционирования ошибках на входе
2 Средства
восстановления при
сбоях оборудования

Рис.4. Модель надежности для фазы анализа

Фактор Критерий Метрика
1
Средства
Надежность Устойчивость восстановления при
функционирования ошибках на входе
2
Средства
восстановления при
сбоях оборудования
Реализация управления
3 средствами
восстановления.

КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Парамзина А.А., Тищенко Е.Н.

Программное обеспечение должно выполнять свои функции, соответствовать заданным критериям качества, безопасности, надежности. Оценка продукта, требований к нему, проектной документации — задача инженеров по обеспечению качества, или QA-инженеров. Обеспечение качества ПО включает в себя мероприятия, которые проводят на каждой стадии его разработки. Цель — предоставить гарантию того, что продукт соответствует функциональным и нефункциональным требованиям.

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Парамзина А.А., Тищенко Е.Н.

Модели, методы, показатели, характеристики и метрики, применяемые в экспертных системах оценки качества разработки и создания инновационных программных проектов

Качество информационных систем
Модель качества программных средств
Место тестирования среди методов оценки качества по

Модель информационно-советующей системы поддержки принятия решения при выборе способа тестирования программного обеспечения

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

SOFTWARE QUALITY

The software must perform its functions, meet the specified criteria of quality, safety, reliability. Evaluation of the product, its requirements, and project documentation is the task of quality assurance engineers, or QA engineers. Software quality assurance includes activities that are carried out at each stage of its development. The goal is to provide a guarantee that the product meets functional and non-functional requirements.

Текст научной работы на тему «КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ»

Парамзина А.А. магистерская программа «Системное и прикладное программное обеспечение»

Ти щенко Е. Н., д. э. н.

информационные технологии и защита информации Ростовский государственный экономический университет (РИНХ)

КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Аннотация: Программное обеспечение должно выполнять свои функции, соответствовать заданным критериям качества, безопасности, надежности. Оценка продукта, требований к нему, проектной документации — задача инженеров по обеспечению качества, или QA-инженеров.

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

Ключевые слова: информационные технологии; анализ; характеристики качества программного обеспечения; модели качества программного обеспечения.

master program «System and application software» Tishchenko E.N., D.Sc. economics

department of information technology and information security

Rostov State University of Economic

Abstract: The software must perform its functions, meet the specified criteria of quality, safety, reliability. Evaluation of the product, its requirements, and project documentation is the task of quality assurance engineers, or QA engineers.

Software quality assurance includes activities that are carried out at each stage of its development. The goal is to provide a guarantee that the product meets functional and non-functional requirements.

Keywords: information technology; analysis; software quality characteristics; software quality models.

1 КРИТЕРИИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

На первый взгляд, «качество ПО» может показаться абстрактным понятием. Однако для менеджеров проекта, программистов, специалистов по тестированию, QA-инженеров и других участников процесса разработки продукта критерии качества прозрачны и измеримы. Сначала рассмотрим общее определение.

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

В настоящий момент этот показатель регулируется международным стандартом КОЛЕС 25010:2011. Данный стандарт устанавливает многоуровневую систему оценки качества ПО, основанную на восьми базовых характеристиках.

ПАРАМЕТРЫ КАЧЕСТВА ПО

Основные характеристики качества программного обеспечения согласно стандарту КОЛЕС 25010:2011:

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

Соответствие стандартам и правилам проектирования

Рисунок 1 — Блок-схема характеристики качества программного

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

последовательность действий для удовлетворения потребительских свойств. Функции бывают целевые (основные) и вспомогательные.

К атрибутам функциональных возможностей относятся:

— защищенность — атрибут, который показывает способность ПО предотвращать несанкционированный доступ (случайный или умышленный) к программам и данным;

— интероперабельность — атрибут, который показывает возможность взаимодействия данного ПО со специальными системами и средами (операционные системы, вычислительные сети);

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

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

К атрибутам функциональной надежности ПО относятся:

— безошибочность — атрибут, который определяет способность ПО функционировать без ошибок;

— правильность — атрибут, который показывает меру достижения правильных результатов;

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

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

— безотказность — атрибут, который характеризует способность ПО не вызывать функциональные отказы информационной системы;

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

— готовность — атрибут, который показывает способность программы по произвольной заявке безошибочно выполнить предусмотренное преобразование.

Юзабилити (удобство использования). Этот параметр характеризует степень удобства ПО для пользователей, его наглядность, легкость эксплуатации и изучения.

К атрибутам удобства применения относятся:

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

— изучаемостъ (легкость изучения) — атрибут, который определяет усилия пользователей, направленные на определение применимости ПО путем использования операционного контроля, диагностики, а также процедур, правил и документации;

— оперативность — атрибут, который показывает реакцию системы при выполнении операций и операционного контроля.

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

К атрибутам эффективности ПО относятся:

— реактивность — атрибут, который показывает время отклика, обработки и выполнения функций;

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

— согласованность — атрибут, который показывает соответствие данной характеристики заданным стандартам, правилам и предписаниям.

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

Сопровождаемость включает следующие атрибуты:

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

— стабильность — атрибут, указывающий на постоянство структуры и риск ее модификации;

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

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

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

Мобильность включает атрибуты:

— адаптивность — атрибут, определяющий усилия, затрачиваемые на адаптацию к различным средам;

— настраиваемость (простота инсталляции) — атрибут, который определяет необходимые усилия для запуска данного ПО в специальной среде;

— сосуществование — атрибут, который определяет возможность использования специального ПО в среде действующей системы;

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

2 МОДЕЛИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Модели качества ПО имеют следующие четыре уровня представления, рассмотрим мы все 4 уровня в модели ISO 9126

Первая модель качества была предложена МакКолом [4-6]. Предложенная модель была в основном предназначена для определения полной характеристики качества программного продукта через его различные характеристики. Модель качества МакКола (см. рис. 2) имеет три главных направления для определения и идентификации качества программного обеспечения:

— использование (корректность, надежность, эффективность, целостность, практичность);

— модификация (тестируемость, гибкость, сопровождаемость -факторы качества важные для разработки новой версии программного обеспечения);

— переносимость (мобильность, возможность многократного использования, функциональная совместимость — факторы качества важные для переносимости программного продукта на другие аппаратные программные платформы).

Рисунок 2 — Модель качества программного обеспечения МакКола

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

В этой модели практичность описывает, как легко, надежно и эффективно программный продукт может быть использован, сопровождаемость характеризует насколько легко изменить и повторно протестировать программный продукт, и мобильность описывает, как

программный продукт может использоваться, даже при изменении программных и аппаратных средств.

Факторы качества Критерии качества

По следовательно сть _проектирован] н_

О j с ле живаемость_

Рисунок 3 — Модель Боэма

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Акроним FURPS, используемый в обозначении модели, обозначает следующие категории требований к качеству ПО:

Functionality (Функциональность) /особенности, возможности, безопасность/;

Usability (Практичность) /человеческий фактор, эргономичность, пользовательская документация/;

Reliability (Надежность) /частота отказов, восстановление информации, прогнозируемость/;

Performance (Производительность) /время отклика, пропускная способность, точность, доступность, использование ресурсов/;

Supportability (Эксплуатационная пригодность) /тестируемость, расширяемость, адаптируемость, сопровождаемость, совместимость, конфигурируемость, обслуживаемость, требования к установке, локализуемость/.

Символ «+» расширяет FURPS модель, добавляя к ней:

— ограничения проекта (ограничения по ресурсам, требования к языкам и средствам разработки, требования к аппаратному обеспечению );

— интерфейс (ограничения накладываемые на взаимодействие с внешними системами);

— требования к выполнению,

— требования к лицензированию.

FURPS модель качества, предложенная Грейди и Hewlett Packard, построена схожим образом с моделями МакКола и Боэма, но в отличие от них состоит из двух слоев, первый определяет характеристики, а второй связанные с ними атрибуты. Основной концепцией, лежащей в основе FURPS модели качества, является декомпозиция характеристик программного обеспечения на две категории требований, а именно, функциональные (F) и нефункциональные (URPS) требования. Эти выделенные категории могут быть использованы как в качестве требований к программному продукту, так и в оценке качества 1111. В настоящее время модель FURPS+ широко используется в разработке программного обеспечения и при идентификации требований к разрабатываемой системе целесообразно использование FURPS+ модели в качестве универсального контрольного перечня характеристик ПО.

Карло Гецци и соавторы [9] различают качество продукта и процесса. Согласно модели Гецци к качеству программного обеспечения относят следующие характеристики программного обеспечения: целостность, надежность и устойчивость, производительность, практичность, верифицируемость, сопровождаемость, возможность многократного использования, мобильность, понятность, возможность взаимодействия, эффективность, своевременность реагирования, видимость процесса разработки.

Модель качества Дроми

Модель качества Дроми [10] основана на критериях оценки. Модель Дроми стремится оценить качество системы, в то время как каждый программный продукт, имеет качество отличное от других. Модель Дроми помогает в предсказании дефектов ПО и указывает на те свойства ПО, пренебрежение которыми может привести к появлению дефектов. Эта модель основывается на отношениях между характеристиками качества и подхарактеристиками, между свойствами программного обеспечения и характеристиками качества ПО. 6 Модель качества SATC

В Центре обеспечения качества программного обеспечения NASA (Software Assurance Technology Center, SATC) была разработана программа метрик [11], обеспечивающая оценку рисков проекта, качества продукции и эффективности процессов. Программа SATC рекомендует отдельно отслеживать качество требований, качество программного обеспечения и

других продуктов (документации), качество тестирования и качество выполнения процессов. Модель качества SATC определяет набор целей, связанных с программным продуктом и атрибуты процессов в соответствии со структурой модели качества программного обеспечения ISO 9126-1.

7 Модель качества ISO-9126

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

Для оценки качества программного обеспечения на основе теории нечетких множеств и метода анализа иерархий, Чанг и др. были определены руководящие принципы, и этот подход ими был применен к модели качества ISO 9126-1. Оценки качества программного обеспечения основаны на характеристиках и подхарактеристиках модели

Шармой А. и др. была предложена компонентно-ориентированная модель качества разработки программного обеспечения, которая включает все характеристики и подхарактеристики модели качества ISO 9126 -1, а также предлагает новые подхарактеристики, такие как пригодность к повторному использованию, гибкость, сложность, прослеживаемость, масштабируемость. Метод анализа иерархий в этой модели используется для оценки качества проекта.

Метрика качества CÁSE-cftetkmu

te ap^kTL^ik’TiiKii уровяя XdpUh ll’lllLL’ 1 Mhll (LIIJhd.kJlï.LII ) КЯЧМТЕЯ JI[h]l'[KMLMJluJl» LlítL [If’Ht’H LtH Клиф. 1 Ц~рии|1И Коаф 3jpUEI Ксаф. 1 \ |X|IHJJL Кшф. i уровня

1 2 3 i 3 fi 7 Я D

1 ФуЕЩИОЕМЬЛЫ£ БйЛИЖНОСТН 0,5

1 Структурные модели футор i il ( i ipumicihib) о,s

1 фуиоцшвмшьи (SADT, IfiEFO) оз

2 DlL3lH!C-I ipumitïnB ( 1DEFH, IPC)

3 ] ] 11 ujn.ib jUHhJbU ( DF 0 )

i C\píjliLlli’llJ[JL- (ST[J h 0.1

2 [тщтю-трийгпфовшЕие mult, ut 11.’ M [. ) 0.1

1 1 Ii-|!LI px.tL’tLH’». lie ищет 0.1

1 1 )r|^niij[ iiiiLÜ i’kiri О,1!

2 (K^ctive DILI^I.LIU 05

4 [ 1 i i. |.H I^JJ.LI i mili UUL- иоде!и ( ]■; К [ I j 0.1

2 Прлпмннк’ть 02

1 Ilik’TpiH’lllli U:i,|i>.li’li 0.Б

) Jhi.ifciuukiujr in j.cumiin.iUMiiiL Jmi.jiMi’iL 0.7

2 C’lHlMrLlll lllru’klllL, ‘.hJl |H.’rLf-1 H-fllbiL- НИЫОЦПЛН ( [ Г1 >1 h> 0.2

3 Нмпш ктршццпП^’ийнчт 0.1

\ Фи|)МЛ ЩНЛИНИ fCkHTHJIUlJ tl ,Jf hkVMi’Jl ГЛ од

2 tHlh|)!lLliU MS OlïlL’l’ А2

3 Фпрьшт RTF о 2

i «hlfUAT 1ITMJ. 02

5 rtii>|]4UiT X.M [_ 02

3 L [in il h HitiH iL Iii h ti^UIMi j.U’lii’TbllH I Ol

i htfl 1 lllhi Lfc- ¡»flh 0.1

S [»iTÍiiriiiitíiLvSnníj» ОД1!

7 OfieliSQLDivïEp« ОД1!

10 h’ilrJilijillL MlJ4 0.0Ü

11″ Нлчмщ] Лп-hlHTl Q.05

1Í (¡tm’U1 Designer 0,1

1 ПЛДД|рЖИ РЧИ’ЫМГ t1|MH|HCti ЖЦ lit] 0.1

] 2 я i 5 С 7 я 3

i Аиа.ш it ирпсктиршилии 0.г1

2 [||л1гкги|>мн.и1и>’ БД il файлов ».1

11 |.ч il рам м и |:ч.’н.и íhc 0.2

i Cf.’tL|H 11и>Ж.\И11 Lie Jj pL»JjJIJJjJIII[Ujlir 0.2

5 УрПВОНЬ LIJIIVrpiipiriUILIllllTII ОД

1 Всшиогэгпныте иршр.ш.ми 0.4

2 1 Lib.’.’L1J. [kJJLpuOllT’IIIK:! 0,iH

E11k Lpy.HiL’irjiL’ihtitJL* i’ролл’тви 1

2 Эффнпншогц 0.2

1 ^TlinUw’Tb [Ю ОС

1 WilUÍ[HVrt J ол

г Windows XP 0.1

я Windows 2003 Server 0.1

i WillJ[lU>, Vii[J ол

(i WlndflWf NT 0.1

ГппррЧ’ЧЩМ! Гил Ü.I

) Ил»? N.m’niit i ь о.п

1 Cuih’cri mj.jiLijn И..1Щ1И OTIÍTO» о.ь

j HjL I 1X1 ■ LК’k Lh¥4lT[lU lHj.lUHIHILll’.H’M. 0J

г lÎLLi . hljL’ 1 lïiitMi ontT4 1

2 C-lctflhk’Tb Jii.i|i,u»iiHU! ШПИЩГНЫХОГКЖ 0.4

l fmnwiiHHin ¡i и pi. M 1 0.4

i 1 gpaijTHiiiLim 0.2

i ГЦин’ЛЯаИПИМЬЭМцМНЛ ai

1 МрХТиТЙ |мГкн и Д5

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Внмнкносгылмгны »мнктирнтш-мннй мидали 0.2

1 IJji.iii’mi’ руса«» №1ТИрф«ЙЛ1 ол

ï Овучмнастъ 0.3

1 УЧЁНЫЙ 1КНТ[) ол

2 КАЛИЧНеДМ^МШТЫДИН IJ5

Докуыатлция m рук вам ним 0.«

J Поддержки niyiNiomH р*Гн>ты и

В заключении, качество программного продукта, нужно, чтобы ориентироваться в многообразии моделей и инструментальных средствах разработки, оценки, метриках и показателях удовлетворительности программного обеспечения. В данной статье мы рассмотрели, что такое качество ПО, какие критерии бывают, что такое модели качества по, на какие группы они делятся, так же на основе модели ISO-9126, увидели все 4 уровня определения качества программных продуктов, аналитики и последующего проектирования системы. Каждая модель несет в себе разные критерии, на котором основываются преимущества и недостатки выбранной модели, так же каждая модель отвечает сертификации и ГОСТу, какую модель мы бы не выбрали, главное проверять программный продукт на качество, тогда мы можем понять подходит ли он для эксплуатации и внедрения на пользовательский рынок или нет. Во всех моделях есть 3 главные составляющие информационной безопасности, а именно целостность, достоверность, конфиденциальность, все программные продукты должны иметь эти критерии.

1. Орлов С. А. Программная инженерия. Учебник для вузов. 5-е издание обновленное и дополненное. Стандарты третьего поколения. — СПб.: Питер, 2018. — 640 с.

2. Сергеев С. Ф., Падерно П. И., Назаренко Н. А. Введение в проектирование интеллектуальных интерфейсов. — СПб.: СПбГУ ИТМО, 2011 — 108 с.

3. Савенко И.И. Технология разработки программного обеспечения: конспект лекции. — Томск: Изд-во Томского политехнического университета, 2014 — 67 с.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *