1. Критерии качества программного средства. Определение качества ПО в стандарте ISO 9126. Многоуровневая модель качества ПО. Оце
Primary tabs
Forums:
Критерии качества программного средства. Определение качества ПО в стандарте ISO 9126. Многоуровневая модель качества ПО. Оценочные характеристики качества программного продукта
Качество определяется в стандарте ISO 9126 как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.
Основными критериями качества ПО (criteria of software quality) являются:
Оценочные характеристики качества:
Размерно-ориентированные метрики
Размерно-ориентированные метрики Основаны на LOC-оценках, т.е. на количестве строк в текстах программ ( ). К числу размерно-ориентированных метрик относятся:
Метрики производительности и качества
Метрики производительности и качества рассчитываются в виде следующих отношений:
где затраты измеряются в человеко-месяцах (работа одного человека в течении месяца)
Качество =
Метрики стоимости и документированности
Достоинства и недостатки Размерно-ориентированные метрик
Достоинства:
Недостатки:
Функционально-ориентированные метрики (FP-оценки)
Исходят не из размера программного продукта, а из его функциональности.
Оценивают:
Вместо количества строк в текстах используется количество функциональных указателей (Function Points)
следующая формула взята из слайдов лекций=
FP-оценки
К числу параметров, учитываемых коэффициентами регулирования сложности относятся:
метода функциональных указателей ((Function Points) – коммерческие информационные системы
Для продуктов с высокой алгоритмической сложностью (системного и встроенного ПО, ПО реального времени) используется метод указателей свойств (Features Points).
При расчете указателя свойств учитывается количество используемых в ПО алгоритмов
Функционально-ориентированные метрики
Функционально-ориентированные метрики аналогичны соответствующим размерно-ориентированным метрикам с точностью до замены =
Достоинства и недостатки Функционально-ориентированных метрик
Достоинства:
Недостатки:
Какой обязательный критерий качества программных систем
Выше было показано, что качество и его оценка в случае с программным обеспечением вычислительных систем – это сложное, не формализуемое и не имеющее однозначной оценки понятие. Тем не менее, отрасль «управление и оценка качества» складывается, и как следствие формируются необходимые понятия и представления на основе научных трудов, стандартов корпораций и отраслевых государственных стандартов.
В [1] приводится достаточно подробная классификация критериев (факторов) качества программного обеспечения. При этом, анализ различных источников показывает, что данные термины наиболее применимы и поддерживаются большинством.
Все критерии качества делятся на «внешние», которые может обнаружить пользователь программного обеспечения, и «внутренние», которые видят только разработчики, создающие это программное обеспечение.
Внешние факторы, которые в том числе описаны в стандарте ИСО 9126:
Примеры внутренних факторов: читаемость, модульность, легкость обнаружения ошибок.
Необходимо отметить, что термины «программное обеспечение» и «конечный пользователь» нужно понимать не только как «конечные прикладные программы» и «оператор или пользователь вычислительной системы», но и как «библиотеки» и «разработчик, использующий библиотеку». Следовательно, такие факторы, как расширяемость и повторное использование, не видны конечному пользователю.
На сегодняшний день большая часть создаваемого программного обеспечения вычислительных систем в мире – это библиотеки и API (к таким продуктам относятся не только библиотеки стандартных классов, такие как STL или Collection Framework, но и, например, ядра операционных систем) и они не являются самостоятельными программными продуктами.
Таким образом, даже если разработчик в одиночку работает над программным обеспечением, он все равно использует огромное количество программного обеспечения, произведенное до него. При работе в команде все равно создается большое количество библиотек программного обеспечения, которые используются или будут использоваться коллегами или самим разработчиком.
Полученные библиотеки могут быть не столь жестко регламентированы, как API ядра операционной системы, которое очень опасно менять от версии к версии. Однако требования к качеству проектирования внутренних интерфейсов никто не отменял, и чем лучше они будут разработаны, тем меньше проблем возникает при их использовании. Кроме того, многие приложения имеют внешние библиотеки для расширения (так называемые plug–in), которые очень близки к API операционных систем.
Обеспечение качества программного обеспечения
Программное обеспечение должно выполнять свои функции, соответствовать заданным критериям качества, безопасности, надежности. Оценка продукта, требований к нему, проектной документации – задача инженеров по обеспечению качества, или QA-инженеров.
Обеспечение качества ПО включает в себя мероприятия, которые проводят на каждой стадии его разработки. Цель – предоставить гарантию того, что продукт соответствует функциональным и нефункциональным требованиям.
Понятие качества программного обеспечения
На первый взгляд, «качество ПО» может показаться абстрактным понятием. Однако для менеджеров проекта, программистов, специалистов по тестированию, QA-инженеров и других участников процесса разработки продукта критерии качества прозрачны и измеримы. Сначала рассмотрим общее определение.
Качество ПО – комплекс характеристик программного продукта, определяющих способность выполнять возложенные на него функции.
В настоящий момент этот показатель регулируется международным стандартом ISO/IEC 25010:2011. Данный стандарт устанавливает многоуровневую систему оценки качества ПО, основанную на восьми базовых характеристиках.
Параметры качества ПО
Основные характеристики качества программного обеспечения согласно стандарту ISO/IEC 25010:2011:
Обеспечение качества и тестирование
Термины «тестирование» и «обеспечение качества», безусловно, связаны между собой, но не тождественны. В чем же различие?
Обеспечение качества отвечает за весь процесс разработки и интегрируется во все его этапы: от создания требований к будущему решению до тестирования, релиза продукта и его пострелизного обслуживания.
В задачи QA-специалистов входит:
Тестирование – проверка программного обеспечения на соответствие требованиям.
Таким образом, вы видите, что обеспечение качества – более широкое понятие, которое включает в себя работы по тестированию.
Тестирование может быть автоматизированным, а может проводиться вручную; может быть полного цикла или направленным на проверку отдельного аспекта качества (безопасность, производительность, удобства использования и т.д.).
Инженеры по тестированию подготавливают стратегии по тестированию и план, основанный на особенностях проекта и требованиям к решению, создают и в будущем оптимизируют набор тест-кейсов, осуществляют поиск дефектов, создают и направляют отчеты об обнаруженных дефектах разработчикам, проверяют устранение дефекта.
Функция обеспечения качества может выполняться внутренним отделом компании, а может делегироваться независимому подрядчику, который объективно оценит само решение, настроит процессы обеспечения качества и тем самым позволит выпустить на рынок продукт высокого качества, отвечающий бизнес-требованиям и ожиданиям пользователей.
Общие сведения о программном обеспечении
На рис.1.1 показаны три основные группы программных технологий. Базовые технологии по мере своего развития влияют на массовые тенденции и дисциплины, и они применяются во всех областях и направлениях программной разработки. Большинство из известных сейчас таких технологий существуют последние 25 лет. Технологические концепции и методологии объединяют базовые методики, которые используются во многих различных отраслях и продуктах. Консолидированные технологии опираются на концепции и предоставляют готовые технические решения. В тех случаях, когда технологии принадлежат к двум таким группам, они отнесены к более общей группе.
На рис.1.1 можно заметить ряд тенденций, характерных для эволюции программного обеспечения за последние годы:
Каждая из этих тенденций оказывает серьезное влияние на инженерные продукты и на формирование программной отрасли. Microsoft с Windows или Sun с Java – пример того, как отдельная компания определяет развитие технологии, но технологии от этих производителей добились успеха благодаря тому, что они создавались и широко распространялись в отраслях. Невозможно даже представить себе Windows без Intel и всей экосистемы поставщиков и провайдеров сервисов. Точно так же банки создали банкоматы и разработали множество связанных с ними программных технологий, таких как распределенная и защищенная обработка транзакций. Компании розничной торговли стимулировали разработку кассовых аппаратов и необходимого программного обеспечения для поддержки цепочки поставки, в том числе штрих-коды и средства радиочастотной идентификации ( RFID ).
Некоторые технологии прошли очень долгий период развития либо никогда не были полностью разработаны. График их перехода к широкому использованию напоминает синусоиду, что свойственно инновациям, которые переходят от этапа начальных исследований и опытных эксплуатаций к широкому отраслевому применению, а затем все повторяется снова [25]. Это объясняет, почему успешные компании практически в одночасье могут потерпеть крах – просто потому, что они своевременно не предложили определенную технологию. Программные менеджеры также часто склонны к стабилизации, а не к росту, – их интересует эффективность, и они недооценивают экспериментирование и инновации.
Программные технологии полезны, если они широко используются. Однако любая конкретная технология в одних отраслях начинает завоевывать популярность быстрее, чем в других. Хороший тому пример – долгая и трудная дорога к пользователям, которую прошли полезные пакеты инструментов для генерации кода и инженерии программного обеспечения. Когда эти пакеты появились вместе с технологией, они еще не были готовы для повсеместного применения, а позже не был готов рынок. Такой же оказалась и судьба экспертных систем и систем искусственного интеллекта. Сейчас они применяются почти везде, поскольку в отрасли осознали, что экспертная система не является автономной технологией, а должна быть интегрирована в другие продукты. На рис.1.2 показан этот эффект на примере обеспечения безопасности информации.
Ориентированность на конкретную предметную область заменила универсальность 1990-х годов. Первые CASEи распределенные компонентные модели увязли в попытках решить сразу слишком большое количество проблем. Когда в отрасли осознали, что различные предметные области имеют свои специфические потребности и скорости внедрения, то оказалось, что достаточно лишь оптимизировать технологию, предложив ее конкретному рынку. Инструменты моделирования сразу же стали пользоваться популярностью после того, как были адаптированы к потребностям конкретных предметных областей, таких как встроенные контроллеры или телекоммуникационные протоколы.
Программные процессы, как для инженерии, так и для управления, стимулировали эволюцию технологий с 1980-х годов. Сложность программных систем растет быстрее, чем люди в состоянии к ней адаптироваться. Эти трудности были уже в 1960-х годах, но тогда ситуация начала терять свою остроту после того, как ведущие отрасли перенесли свое внимание на процесс инженерии программного обеспечения. Как следствие, разработка программного обеспечения за последние 25 лет кардинально изменилась, превратившись из индивидуального творчества в дисциплину программной инженерии.
Сейчас трудно поверить, что 25 лет назад большая часть программного обеспечения и его разработчики и пользователи действовали изолированно. Программная интеграция лучше всего стала видна с появлением Интернета и его огромными темпами роста, благодаря развитию средств взаимодействия. Компонентные платформы и открытые стандарты еще больше усиливают эту тенденцию. Успешное внедрение и интеграция отнюдь не тривиальны – чтобы предложить что-то полезное инженерам, новые технологии, процессы и средства инженерии нуждаются в аппарате глубокого управления изменениями.
1.3. Качество и характеристики программного обеспечения
Рассматривая, оценивая и анализируя программные системы и отдельные программы, останавливаются на показателях качества программ и их основных характеристиках. Качество ПО – это совокупность свойств, определяющих полезность изделия (программы) для пользователей в соответствии с функциональным назначением и предъявленными требованиями. Характеристика качества программы – понятие, которое отражает отдельные факторы, влияющие на качество программ и поддающиеся измерению [23].
Каждая ПС должна выполнять определенные функции, т.е. делать то, что задумано. Хорошая ПС должно обладать еще целым рядом свойств, позволяющим успешно ее использовать в течение длительного периода, т.е. обладать определенным качеством. Качество ( quality ) ПС – это совокупность его характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей [23]. Это не означает, что разные ПС должны обладать одной и той же совокупностью таких свойств в их наивысшей степени. Повышение качества ПС по одному из таких свойств часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и снижения качества этой ПС по другим его свойствам. Качество ПС является удовлетворительным, когда она обладает указанными свойствами в такой степени, чтобы гарантировать успешное ее применение.
Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этой ПС, т.е. от позиции, с которой должно рассматриваться качество этой ПС. Поэтому при описании качества ПС, прежде всего, должны быть фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС ( criteria of software quality ) принято считать:
Во многих случаях функциональность и надежность являются обязательными критериями качества ПС, причем обеспечение надежности красной нитью проходит по всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС.
К основным характеристикам программ и программных систем относится сложность программной системы. При оценке сложности программ, как правило, выделяют три основные группы метрик [23]:
Оценки первой группы наиболее просты и, очевидно, поэтому получили широкое распространение. Традиционной характеристикой размера программ является количество строк исходного текста. Под строкой понимается любой оператор программы, поскольку именно оператор, а не отдельно взятая строка является тем интеллектуальным «квантом» программы, опираясь на который можно строить метрики сложности ее создания.
Непосредственное измерение размера программы, несмотря на свою простоту, дает хорошие результаты. Конечно, оценка размера программы недостаточна для принятия решения о ее сложности, но вполне применима для классификации программ, существенно различающихся объемами. При уменьшении различий в объеме программ на первый план выдвигаются оценки других факторов, оказывающих влияние на сложность. Таким образом, оценка размера программы есть оценка по номинальной шкале, на основе которой определяются только категории программ без уточнения оценки для каждой категории.
К группе оценок размера программ можно отнести также и метрику Холстеда. Основу метрики Холстеда составляют четыре измеряемых характеристики программы:
– число уникальных операторов программы, включая символыразделители, имена процедур и знаки операций (словарь операторов);
– число уникальных операндов программы (словарь операндов); N1 – общее число операторов в программе;
– общее число операндов в программе.
Опираясь на эти характеристики, получаемые непосредственно при анализе исходных текстов программ, М. Холстед вводит следующие оценки:
словарь программы 
,
Критерии качества программных средств
Критерии оценки эффективности и качества создания программных средств. Роль трудоемкости и длительности создания программных средств в определении эффективности их создания. Требования к качеству, суммарные затраты на разработку программного средства.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | реферат |
| Язык | русский |
| Дата добавления | 10.10.2014 |
| Размер файла | 26,7 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Критерии качества программных средств
Введение
Целью данной работы является изучение основных критериев оценки эффективности создания программных средств. Для достижения поставленной цели необходимо решить следующие задачи:
— изучить теоретического материала по выбранной теме;
— рассмотреть понятие качества программного средства;
— описать процесс определения трудоемкости и длительности создания программных средств.
Качество программных средств
Качество программного средства — это совокупность его свойств и характеристик, влияющих на его способность удовлетворять заданные потребности пользователей. Но это не означает, что различные программные средства должны обладать одной и той же совокупностью таких характеристик. Качество программного средства является удовлетворительным тогда, когда оно обладает указанными для него характеристиками и свойствами в такой степени, чтобы гарантировалось его успешное использование.
1. Завершенность — свойство, которое характеризует степень обладания ПС всеми необходимыми частями, которые необходимы для выполнения явных и неявных функций;
программное средство качество затрата
2. Точность — это мера, которая определяет величину погрешности в выдаваемых результатах;
3. Автономность — это свойство, которое характеризует способность ПС выполнять предписанные функции без участия других программных компонент;
4. Устойчивость — это свойство, которое характеризует способность программного продукта продолжать корректное функционирование, несмотря на задание неверных входных данных;
5. Защищенность — это способность ПС противостоять преднамеренным или нечаянным разрушающим действиям пользователя;
7. Информативность — свойство, которое характеризует наличие в составе программного средства информации, которая необходима и достаточна для понимания назначения данного программного средства.
8. Коммуникабельность — свойство, которое характеризует степень, в которой программное средство облегчает задание или описание входных данных и способность выдавать советы пользователю в достаточно простой форме и простым содержанием;
9. Временная эффективность — мера, которая характеризует способность программного средства выполнять возложенные на него функции в течение определенного отрезка времени;
10. Эффективность по ресурсам — способность программного средства выполнять возложенные на него функции при определенных ограничениях на используемые ресурсы (используемую память);
11. Эффективность по устройствам — это экономичность использования устройств ЭВМ для решения поставленных задач;
13. Понятность — степень, в которой программный продукт позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и текст программ;
14. Удобочитаемость — характеризует легкость восприятия текста программ ПС.
15. Расширяемость — способность ПС к использованию больших объемов памяти для хранения данных или расширению его функциональных возможностей при изменении условий эксплуатации;
16. Модифицируемость — характеризует ПС с точки зрения внесения необходимых изменений и доработок на всех стадиях ЖЦ;
17. Модульность — характеризует программное средство с точки зрения организации его программ из таких дискретных элементов, что изменение одного из них вызывает минимальные воздействия на другие элементы и компоненты программного средства.
18. Независимость от устройств — способность ПС работать на разнообразном аппаратном обеспечении;
Из наборов примитивов качества выстраиваются критерии качества.
Совокупность свойств, которые образуют удовлетворительное для пользователя качество программного средств, зависит от характера и условий эксплуатации этого программного продукта.
Поэтому при описании качества программного средства, прежде всего, должны быть зафиксированы критерии отбора требуемых свойств и характеристик.
В процессе разработки технического задания выявляются основные показатели, устанавливается относительная важность каждого из этих показателей и строится обобщённая целевая функция требуемого качества программного средства, а также устанавливаются допустимые затраты и длительность разработки программного продукта. После завершения отладки и испытаний эти показатели и обобщённая функция уточняются на предмет их соответствия техническому заданию. Различают конструктивные и функциональные критерии качества программного средства. Первые критерии оценивают сложность программного средства, его надёжность функционирования, корректность, ресурсы ЭВМ и др. Вторые отражают специфику применения и степень соответствия программного средства их целевому назначению. В ряде случаев их можно свести к показателям обобщённой экономической эффективности применения ПС в ЖЦ, характеризуемой величиной экономии труда, энергии, материалов и т.п. [5]
К критериям качества относят:
2) Надежность — способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью;
3) Легкость применения — это характеристика ПС, которое позволяет минимизировать усилия пользователя при оценке полученных результатов, при подготовке исходных данных и в целом при применении программного средства,
4) Эффективность — отношение уровня услуг, предоставленных ПС пользователю к объему используемых ресурсов при заданных условиях;
5) Сопровождаемость — характеристика ПС, которая позволяет минимизировать усилия по внесению изменений при устранении ошибок и модификации;
6) Мобильность — способность ПС быть переносимым из одной сферы окружения в другую.
Функциональность и надежность являются обязательными качествами. При чем, обеспечение надежности будет происходить по всем этапам и процессам разработки ПС, а остальные критерии используются в зависимости от потребности пользователей в соответствии с требованиями ПС.
Разработка программного средства завершается его аттестацией. Аттестация программного средства — это авторитетное подтверждение его качества. Как правило, для аттестации создается комиссия экспертов. Эта комиссия проводит приемо-сдаточные испытания программного средства с целью получения необходимой информации для оценки его качества.
Таким образом, оценка качества программного средства является основным в процессе аттестации, причем оценка качества производится по предъявленной спецификации его качества, т.е. оценивается только установленные критерии качества и примитивы качества.
Существует три метода оценки примитивов качества:
1) Непосредственное измерение показателей примитива качества. Заключается в проверке соответствия предъявленной документации на программное средство, включая тесты программ, стандартам или явным требованиям к программному средству, указанным в спецификации качества. Кроме того, оценка производится путем измерения времени работы различных устройств и используемых ресурсов при выполнении контрольных тестов.
3) Для оценки некоторых примитивов качества используется тестирование, например, для таких примитивов как завершенность, устойчивость, точность, защищенность и т.д. Во время аттестационных испытаний нет необходимости проводить полное тестирование, аттестационная комиссия прежде всего изучает предъявленную документация и выборочно пропускает составленные тесты. Могут возникать у комиссии сомнения по поводу работоспособности ПС, тогда составляются допустимые тесты и проводится тестирование.