Разработка, внедрение и адаптация программного обеспечения отраслевой направленности Часть 2. Разработка, внедрение и адаптация программного обеспечения отрас. Тема введение в обеспечение качества программных средств

• Название: Тема введение в обеспечение качества программных средств
• Анкор: Разработка, внедрение и адаптация программного обеспечения отраслевой направленности Часть 2
• Дата: 15.03.2023
• Размер: 418.37 Kb.
• Имя файла: Разработка, внедрение и адаптация программного обеспечения отрас.docx
• Тип: Глава; #990789
• страница: 10 из 31

5.9. Модель качества в использовании

В стандарте ISO/IEC 9126-1:2001 приведена модель качества в использовании (рис.8).

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

Качество в использовании (Quality in use)    - это способность программного средства позволять пользователям достигать специфицированные цели с результативностью, продуктивностью, безопасностью и удовлетворенностью в заданном контексте использования. Качество в использовании представляет собой объединенный эффект характеристик качества программного средства для пользователя. Качество в использовании - это восприятие пользователем качества системы, содержащей программные средства. Оно измеряется в терминах результатов использования комплекса программ, а не собственных внутренних свойств программных средств.

Качество в использовании разделяется на четыре характеристики:

результативность, продуктивность, безопасность, удовлетворенность.

Рис.8. Модель качества в использовании

Результативность (Effectiveness)    - это способность программного средства позволять пользователям достигать специфицированные цели с точностью и полнотой в заданном контексте использования.

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

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

Удовлетворенность (Satisfaction)    - это способность программного средства удовлетворять пользователя в заданном контексте использования.

5.10. Внешние и внутренние метрики качества программных средств

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

Формализации внешних и внутренних метрик характеристик качества программного средства посвящены соответственно вторая и третья части стандарта ISO/IEC 9126-2, 3.

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

Все таблицы унифицированы. В них содержатся:

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

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

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

• 
  характеристика;
  
• 
  подхарактеристика;
  
• 
  мера;
  
• 
  уровень требований;
  
• 
  измеренное действительное значение.
  

Для отдельных метрик допускаются качественные значения и ранжирование уровня требований:

• 
  высокий, средний, низкий; или
  
• 
  отличный, хороший, удовлетворительный, неудовлетворительный.
  

Описаны свойства типов применяемых шкал метрик. Это:

• 
  номинальная;
  
• 
  категорийная;
  
• 
  ординарная (порядковая);
  
• 
  интервальная;
  
• 
  относительная;
  
• 
  абсолютная.
  

Даны типы измеряемых величин.

Фрагменты таблиц метрик из данных частей стандарта приведены при описании характеристик и подхарактеристик внешнего и внутреннего качества (см. подразд. 4.2.1 - 4.2.6).

5.11. Метрики качества в использовании

Метрики качества в использовании    описаны в четвертой части стандарта ISO/IEC 9126-4. Данная часть предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества программных средств.

В данной части стандарта представлена модель взаимодействия компонентов качества в использовании (рис.10).

Для качества в использовании рекомендуется применять четыре характеристики:Результативность, Продуктивность, Безопасность, Удовлетворенность. Для этих характеристик даны рекомендации по подготовке к их оцениванию:

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

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

Процессы выбора метрик и шкал для описания показателей качества программного средства делятся на два этапа:

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

На первом этапе базовая номенклатура характеристик и подхарактеристик (ISО/IЕС 9126-1) предварительно упорядочивается по приоритетам с учетом области применения проекта программного средства.

Затем ранжируются по приоритетам потребители с учетом их профессиональных интересов. Обычно выделяются следующие группы потребителей:

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

2. Заказчики; оценивают качество программного средства, чаще всего, по внешним мерам функциональных возможностей, надежности, практичности и эффективности;

3. Коллектив сопровождения; оценивает качество программного средства по метрикам сопровождаемости;

4. Лица, устанавливающие программные средства в различных аппаратных и операционных средах; оценивают качество программного средства по метрикам мобильности;

5. Разработчики, технологи-инструментальщики, специалисты системы качества, поддерживающие жизненный цикл программного средства; оценивают качество программного средства по внутренним метрикам каждой характеристики качества.

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

ГЛАВА 6. ТЕМА 5. СТАНДАРТИЗАЦИЯ В ПЛАНИРОВАНИИ ПРОЕКТА ПО РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

6.1. Введение в стандартизацию планирования проекта по разработке программного обеспечения

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

Одним из основных аспектов разработки программного обеспечения является использование методологии управления проектами в основе которых лежат методики сетевого планирования. Данные методы были разработаны в конце 50-х годов на территории США. Одним из основоположником методологий управления проектами стал М. Уолкер   . В 1956 году он работая в компании "Дюпон" исследовал возможности более эффективного использования вычислительной машины Univac принадлежавшей компании. Объединив свои усилия с Д. Келли    из группы планирования капитального строительства строительства фирмы "Ремингтон Рэнд", они попытались использовать ЭВМ для сверки планов-графиков крупных комплексов работ по модернизации заводов принадлежавших компании "Дюпон". В результате их работ была разработана простая методология работы над проектом с использованием ЭВМ. Данный метод был назван методом Уолкера-Келли и позднее получил название Метода критического пути (CPM – Critical path method)   .

Параллельно и независимо в военно-морских силах США был создан метод анализа и оценки программ PERT    (Program Evaluation and Review Technique). Данный метод был разработан корпорацией "Локхид" и консалтинговой фирмой "Буз, Аллен энд Гамильтон" для реализации проекта разработки ракетной системы "Поларис", объединяющего около 3800 основных подрядчиков и состоящего из 60 тыс. операций.

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

Широкое применение методика планирования работ на основе проекта получила в строительстве. Например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась с 1967 по 1976 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1974 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат.

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

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

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

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

Проект - это временное предприятие, предназначенное для создания уникальных продуктов или услуг.

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

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

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