Характеристики качества программного обеспечения. Основные принципы управления качеством программного обеспечения

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Введение

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

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

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

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

Чтобы убедиться в справедливости этих утверждений, сравним два подхода к определению успешности проекта:

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

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

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

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

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

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

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

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

В настоящее время существует несколько схем взаимодействия между заказчиком и разработчиком ПО:

«Свой» заказчик

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

· доступность заказчика в любое время;

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

· достаточно гибкие требования к качеству программного обеспечения;

· постоянное сопровождение своих продуктов, их доработка и совершенствование;

· устойчивые финансовые взаимоотношения между заказчиком и разработчиками;

· долгосрочные планы по сотрудничеству.

Продукт под заказ

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

· доступность заказчика можно охарактеризовать как «периодическую»;

· представление о нуждах и потребностях заказчика формируется на базе произведенного обследования;

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

· финансовые отношения оформляются в виде разового контракта;

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

Тиражируемый продукт

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

· конкретного заказчика, формирующего требования к продукту, не существует;

· представление о нуждах и потребностях настоящих и потенциальных пользователей формируются на основе анализа рынка и контактов с типичными представителями пользователей. Обратная связь с пользователями продукта осуществляется в основном посредством электронной почты или «горячей линии»;

· качество программного обеспечения контролируется только внутренним отделом качества + обратная связь с пользователями. Широко используется бета-тестирование;

· разработчик в течение заранее оговоренного периода времени поддерживает поставленный продукт;

· финансовые отношения существуют в виде фиксированной цены на продукт;

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

Аутсорсинг

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

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

· представление о нуждах и потребностях заказчика формируются только на основе информации, представленной фирмой-подрядчиком;

· подрядчик предоставляет свои требования к процессу производства ПО и его качеству;

· поддержку продукта, как правило, осуществляет подрядчик;

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

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

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

1. Стандарты качества программного обеспечения

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

Определение ISO: Качество - это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям.

Определение IEEE: Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств.

Основным стандартом качества в области инженерии программного обеспечения в настоящее время является стандарт ISO/IEC 9126:1-4:2002 (ГОСТ Р ИСО/МЭК 9126-93). В дополнение к нему выпущен набор стандартов ISO/IEC 14598, регламентирующий способы оценки характеристик качества. В совокупности они образуют модель качества, известную под названием SQuaRE (Software Quality Requirements and Evaluation).

В соответствии со стандартом ISO 9126 общее представление о качестве программного средства (ПС) рекомендуется описывать тремя взаимодействующими и взаимозависимыми метриками характеристик качества, отражающими:

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

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

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

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

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

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

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

Рис. 3.1. Система измерения качества

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

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

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

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

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

· количественные метрики применимы для измерения надежности и эффективности сложных комплексов программ;

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

Вторая и третья части стандарта -- ISO 9126-2 и ISO 9126-3 -- посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных программных средств. Все таблицы содержат унифицированную рубрикацию, где отражены имя и назначение метрики; метод ее применения; способ измерения, тип шкалы метрики; тип измеряемой величины; исходные данные для измерения и сравнения; а также этапы жизненного цикла программного средства (по ISO 12207), к которым применима метрика. Четвертая часть стандарта -- ISO 9126-4 -- предназначена для покупателей, поставщиков, разработчиков, службы сопровождения ПО, пользователей и менеджеров качества. В ней обосновываются и комментируются выделенные показатели сферы использования программных средств и группы выбранных метрик для пользователей. Характеристики, используемые для оценки качества программного обеспечения, и уточняющие их субхарактеристики сведены в таблицу 3.1.

Табл. 3.1. Характеристики качества программного обеспечения

Функциональные возможности (Functionality) Данный набор атрибутов качества характеризует то, что программное обеспечение делает для удовлетворения потребностей пользователя, тогда как другие наборы, главным образом, характеризуют, когда и как это выполняется.	Способность программного обеспечения реализовать установленные или предполагаемые потребности пользователей
Пригодность для применения по назначению (Suitability)	Наличие и соответствие набора функций конкретным задачам
Правильность/корректность реализации требований (Accuracy) Например, необходимая степень точности вычисленных значений.	Способность программного обеспечения обеспечивать правильность (или соответствие) результатов
Способность к взаимодействию с компонентами и средой (Interoperability) Способность к взаимодействию используется вместо совместимости для того, чтобы избежать возможной путаницы с взаимозаменяемостью.	Способность ПО взаимодействовать с конкретными системами
Согласованность (Compliance)	Способность программного обеспечения придерживаться соответствующих стандартов или соглашений, или подробных рекомендаций
Защищенность/безопасность функционирования (Security)	Способность ПО предотвращать несанкционированный доступ (случайный или преднамеренный) к программам и данным
Надежность (Reliability) Износа или старения программного обеспечения не происходит. Ограничения надежности проявляются из-за ошибок возникающих на этапе определения требований, проектирования и реализации. Отказы из-за этих ошибок зависят от способа использования программного обеспечения и ранее выбранных версий программ.	Способность программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени
Стабильность/уровень завершенности (Maturity)	Характеризуется частотой отказов, вызванных наличием ошибок в программном обеспечении
Устойчивость к ошибке (Fault tolerance)	Способность программного обеспечения поддерживать определенный уровень качества функционирования в случаях программных ошибок или нарушения определенного интерфейса
Восстанавливаемость после проявления дефектов (Recoverability) Восстанавливаемость характеризуется двумя аспектами: легкостью устранения дефектов разработки (ремонтопригодность) и легкостью технического обслуживания программного продукта в условиях его эксплуатации (поддерживаемость). Понятие дефект можно определить как некоторый аспект системы, препятствующий выполнению поставленных перед ней задач. Дефекты могут быть вызваны ошибками, допущенными при разработке, либо возникнуть из-за недопонимания требований, предъявляемых к системе. Система считается восстанавливаемой, если устранение системных дефектов является экономически эффективным . Восстанавливаемость можно обеспечить при наличии следующих двух условий: источники дефектов легко устранить, устранение одного дефекта не порождает другого. Обычно ПО является восстанавливаемым, если при проектировании системы было четко указано какие функции должна выполнять каждая из частей программы. Одним из признаков некачественной программы является уязвимость программного кода: каждый раз при устранении дефекта возникают проблемы в других частях программы.	Способность программного обеспечения восстанавливать уровень качества функционирования и данные, непосредственно поврежденные в случае отказа. Характеризуется необходимыми для этого затратами усилий и времени
Практичность (Usability) Круг пользователей может включать операторов, конечных пользователей и косвенных пользователей, на которых влияет данное программное обеспечение или которые зависят от его использования. Практичность должна рассматриваться во всем разнообразии условий эксплуатации пользователем, которые могут влиять на программное обеспечение, включая подготовку к использованию и оценку результатов.	Характеризуется объемом работ, требуемых для использования программного обеспечения определенным или предполагаемым кругом пользователей
Понятность функций и документации (Understandability)	Характеризует усилия пользователя по пониманию общей логической концепции ПО и его применимости
Изучаемость процессов функционирования и применения (Learnability)	Характеризует усилия пользователя по обучению применению программного обеспечения (например, оперативному управлению, вводу, выводу)
Простота использования (Operability)	Характеризует усилия пользователя по эксплуатации и оперативному управлению ПО
Эффективность (Efficiences) Ресурсы могут включать другие программные продукты, технические средства, расходные материалы (например, бумагу для печати, гибкие диски) и услуги эксплуатирующего, сопровождающего или обслуживающего персонала.	Определяется соотношением между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях
Временная эффективность реализации комплекса программ (Time behavior)	Характеризуется временем отклика и скоростью выполнения функций
Используемость вычислительных ресурсов (Resource behavior)	Характеризуется объемом используемых ресурсов и продолжительностью использования ПО при выполнении функции
Сопровождаемость (Maintainability) Изменение может включать исправления, усовершенствование или адаптацию программного обеспечения к изменениям в окружающей обстановке, требованиях и условиях функционирования.	Характеризует объем работ, требуемых для проведения конкретных изменений (модификаций)
Анализируемость (Analysability)	Характеризует усилия, необходимые для диагностики недостатков или случаев отказов или определения составных частей для модернизации
Изменяемость компонентов и комплекса программ (Changeability)	Характеризует усилия, необходимые для модификации, устранения отказа или для изменения условий эксплуатации
Устойчивость (Stability)	Характеризует риск от непредвиденных эффектов модификации
Тестируемость изменений при сопровождении (Testability)	Характеризует усилия, необходимые для проверки модифицированного программного обеспечения
Мобильность (Portability) Окружающая обстановка может включать организационное, техническое или программное окружение.	Способность программного обеспечения быть перенесенным из одного окружения в другое
Адаптируемость к изменениям среды (Adaptability)	Характеризует удобство адаптации ПО к различным конкретным условиям эксплуатации, без применения других действий или способов, кроме тех, что предназначены для этого в рассматриваемом программном обеспечении
Простота установки/внедрения/инсталляции после переноса (Installability)	Характеризует усилия, необходимые для внедрения программного обеспечения в конкретное окружение
Соответствие (Confortncnce)	Способность программного обеспечения подчиняться стандартам или соглашениям, относящимся к мобильности
Взаимозаменяемость компонентов при корректировке комплекса программ (Replaceability) Взаимозаменяемость с конкретным программным средством не предполагает, что данное средство заменимо рассматриваемым программным средством. Взаимозаменяемость может включать атрибуты простоты внедрения и адаптируемости.	Характеризует простоту и трудоемкость применения данного ПО вместо другого конкретного программного средства в среде этого средства

2. Управление качеством ПО на стадиях жизненного цикла

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3.2: Время простоя ПО при различных значениях показателя работоспособности

Работоспособность

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

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

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

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

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

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

Итак, инвесторов, в основном, интересуют три аспекта:

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

· эксплуатационная стоимость, которая увеличивает расходы, что может привести к снижению прибыли.

· стоимость интеллектуальной собственности.

Значимость основных характеристик качества для каждого из участников программного проекта схематично отражена в таблице 3.3.

Атрибут качества	Пользователь	Покупатель	Инвестор
Функциональность
Надежность
Практичность
Эффективность
Сопровождаемость
Мобильность

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

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

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

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

Руководителя программного проекта должно интересовать, какова будет стоимость разработки качественного ПО, и может ли компания позволить себе такие расходы. Какой уровень качества будет «по карману» для той или иной разработки?

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

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

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

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

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

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

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

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

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

Однако время не стоит на месте, и методики, положенные в основу стандарта ISO 9001, постепенно устаревают. Наиболее существенными его недостатками считаются:

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

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

· отсутствие в стандарте механизмов, способствующих улучшению существующих процессов.

Перечисленные проблемы заставили профессиональное сообщество программистов разрабатывать более совершенные решения в области обеспечения качества, что привело к созданию в начале 90-х годов целого ряда новых стандартов и методологий. Примерами наиболее удачных и содержательных стандартов могут служить Capability Maturity Model (CMM) и ISO/IEC 15504 (SPICE).

Capability Maturity Model

Официальная история CMM Capability Maturity Model обычно переводят как «модель зрелости процесса разработки ПО», хотя более верным по смыслу был бы перевод «модель совершенствования возможностей». начинается в 1991 году, когда американский институт программной инженерии SEI, существующий при университете Карнеги-Меллон, опубликовал первую версию этого стандарта.

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

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

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

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

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

Рис. 3.2. Пять уровней зрелости в модели CMM.

Начальный уровень (initial level) описан в стандарте в качестве основы для сравнения со следующими уровнями. Если компания-разработчик находится на начальном уровне организации, в ней фактически не существует стабильных условий для создания качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят из компании, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.

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

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

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

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

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

При сертификации проводится оценка соответствия всех ключевых областей по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям:

...

Подобные документы

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

презентация , добавлен 14.08.2013


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

реферат , добавлен 10.09.2010


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

курсовая работа , добавлен 23.08.2011


Основные процессы разработки, приобретения и внедрения сложных систем. Семейство стандартов ISO 9000. Зрелые и незрелые организации-разработчики программного обеспечения. Основные направления формирования метрик для оценки компьютерных программ.

дипломная работа , добавлен 27.11.2012


Современные инструменты разработки программного обеспечения для СУТП. Универсальные языки программирования и сравнение их со SCADA-системами. Разработка программного обеспечения с использованием многоканальных измерительных преобразователей Ш9327.

дипломная работа , добавлен 13.07.2011


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

курсовая работа , добавлен 24.06.2012


Цели и задачи программной инженерии. Понятие программного обеспечения. Шесть принципов эффективного использования программного обеспечения. Виды программного обеспечения: общесистемное, сетевое и прикладное. Принципы построения программного обеспечения.

курсовая работа , добавлен 29.06.2010


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

курсовая работа , добавлен 07.04.2015


Изучение основных видов угроз программного обеспечения. Выявление наиболее эффективных средств и методов защиты программного обеспечения. Анализ их достоинств и недостатков. Описания особенностей лицензирования и патентования программного обеспечения.

курсовая работа , добавлен 29.05.2013


Общий календарный план выполнения этапов проекта программного обеспечения. Последовательность разработки согласно классической каскадной модели. Изображение хода работ по спиральной модели согласно Боему. Технические требования на продукт, WBS-структура.

Аннотация: Рассматриваются характеристики качества программных продуктов. Отмечается, что вопросы качества должны решаться на протяжении всего жизненного цикла. Показано, тестирование программного продукта позволяет гарантировать заданные параметры качества. Рассматриваются различные типы тестов и инструментарий тестирования в VisualStudio 2012. Показано, что рефакторинг кода улучшает качество программного продукта.

Презентацию к данной лекции Вы можете скачать .

Цель лекции:

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

Введение

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

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

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

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

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

Тестирование программного обеспечения

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

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

Модульное тестирование	предназначено для проверки правильности функционирования методов классов ПО. Модульные тесты пишутся и исполняются разработчиками в процессе написания кода. Модульное тестирование применяется как для проверки качества кода приложения, так и для проверки объектов баз данных.
	предназначено для тестирования, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки.
Интеграционное тестирование	используется для проверки корректности совместной работы компонентов программного продукта.
Функциональное тестирование	предполагает проверку конкретных требований к ПО и проводится после добавление к системе новых функций.
Нагрузочное тестирование	предназначено для проверки работоспособности программного продукта при предельной входной нагрузке.
Регрессионное тестирование	применяется при внесении изменений в программное обеспечение с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом.
Комплексное тестирование	предназначено для тестирования функциональных и нефункциональных требований всей системы программного продукта.
Приемочное тестирование	представляет собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков. Приемочные тесты пишутся бизнес-аналитиками, специалистами по контролю качества и тестировщиками.

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

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

Инструментарием тестировщика в VisualStudio 2012 является MicrosoftTestManager (MTM). MTM предназначен для управления жизненным циклом тестирования программного обеспечения, включая планирование, тестирование и мониторинг . MTM интегрирован с TeamFoundationServer. С помощью Microsoft TestManager тестировщики подготавливают планы тестирования, управляют тестированием. При создании плана тестирования в него добавляются наборы тестов, тестовые случаи и конфигурации, необходимые для тестирования. Конфигурации используются для установления среды, в которой будут исполняться наборы тестов. Microsoft TestManager позволяет выполнять ручные и автоматические тесты, а также исследовательские тесты. Результаты тестирования сохраняются в базе данных, что позволяет подготавливать различные аналитические отчеты. Ошибки, выявленные в процессе тестирования, фиксируются, документируются и передаются разработчикам для их устранения. При внесении изменений в код программной системы возникает необходимость в регрессионном тестировании, причем MTM автоматически формирует план регрессионного тестирования, выявляя какие тесты должны быть повторно выполнены.

Для тестировщиков и разработчиков программного обеспечения VisualStudio 2012 включает диспетчер виртуальной среды LabManagement. Инструментарий тестирования LabManagement позволяет создать инфраструктуру, которая максимально близко эмулирует реальную среду планируемого использования программного продукта. Такие среды могут использоваться для выполнения автоматических построений, автоматизации тестов и выполнения разработанного кода.

Рефакторинг

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

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

Некачественный дизайн кода определяется по ряду признаков :

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

Для создания качественного дизайна кода целесообразно применять некоторые принципы и паттерны проектирования ПО [ , ].

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

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

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

Принцип инверсии зависимостей определяет два положения:

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

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

Паттерны проектирования предлагают универсальные, проверенные практикой решения. В приведен обширный перечень паттернов. Среди общего списка паттернов следует выделить те, которые целесообразно применять при гибкой разработке программного обеспечения. Это паттерны Команда , Стратегия, Фасад, Посредник, Одиночка, Фабрика, Компоновщик, Наблюдатель, Абстрактный сервер/адаптер/ шлюз , Заместитель и Шлюз , Посетитель и Состояние.

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

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

Ключевые термины

Модульное тестирование	тестирование, предназначенное для проверки правильности функционирования методов классов ПО.
Исследовательское тестирование	тестирование, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки.
Интеграционное тестирование	тестирование, предназначенное для проверки корректности совместной работы компонентов программного продукта.
Функциональное тестирование	тестирование, предназначенное для проверки конкретных требований к ПО, которое проводится после добавление к системе новых функций.
Нагрузочное тестирование	тестирование, предназначенное для проверки работоспособности программного продукта при предельной входной нагрузке.
Регрессионное тестирование	тестирование, применяемое при внесении изменений в программное обеспечение, с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом.
Комплексное тестирование	тестирование, предназначенное для проверки соответствия функциональных и нефункциональных требований всей системы программного продукта.
Приемочное тестирование	тестирование, представляющее собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков.
MicrosoftTestManager	инструментарий Microsoft, предназначенный для управления жизненным циклом тестирования программного обеспечения.
LabManagement	диспетчер виртуальной среды тестирования.

Набор для практики

Вопросы

1. Какими характеристиками должен обладать качественный программный продукт?
2. Какие нефункциональные требования определяют качество программного продукта?
3. Какая роль тестирования в обеспечении качества программного продукта?
4. Какие типы тестов используют для проверки качества программного продукта?
5. Для чего применяется регрессионное тестирование?
6. Какие шаблоны тестовых проектов имеются вVisualStudio 2012?
7. Для чего применяется MicrosoftTestManager? Какие он имеет функциональные возможности?
8. Для чего используется LabManagement при тестировании?
9. Для чего применяют рефакторинг кода?
10. Приведите признаки некачественного кода.

Упражнения

1. Подготовьте аналитический обзор по NUnit тестированию.
2. Подготовьте аналитический обзор по xUnit.net тестированию.
3. Подготовьте аналитический обзор по MbUnit тестированию.

1

В работе приведена краткая информация по стандарту 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).

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

1) качество программного обеспечения - это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. ;

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

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

Стандарт ISO 9126

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

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

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

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

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

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

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

В настоящее время все чаще стали появляться готовые средства для разработки обучающих программ . Причем эти разработки не только зарубежных (для примера - 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, при помощи которой можно регистрировать пользователей, объединять их в группы, назначать тесты для выполнения пользователями, просматривать и распечатывать результаты тестирования.

Кроме указанных программных комплексов, существует множество других систем . С некоторыми из них можно познакомиться на сайте - 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. Именно эти системы наиболее часто используют на практике при тестировании студентов.

Заключение

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

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

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

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

	Название			«Конструктор тестов»		VeralTest Express / Professional
	Надежность
	Завершенность (вероятность отказа)					Низкая / Высокая
	Устойчивость к отказам (работоспособность)
	Восстанавливаемость
	Наличие системы резервного копирования
	Сохранение тестов в отдельном файле
	Удобство использования
	Легкость освоения
	Наличие методических указаний по изучению
	Понятность
	Наличие готовых шаблонов тестов		+ (на англ.)
	Наличие развернутой справочной системы
	Удобство и простота использования
	Наличие меню (кнопки) создания теста
	Работа с графикой
	Работа со звуком
	Создание кнопок управления
	Возможность автоматического оценивания ответа
	Задание сроков ответов на вопросы
	Наличие функции определения времени ответа на вопросы
	Ограничение времени ответ на каждый вопрос
	Ограничение общего времени прохождения теста
	Возможность деления вопросов по уровням сложности
	Функциональность
	Наличие средств защиты (например, шифрование тестов)
	Возможность работы локальной компьютерной сети
	Работа в сети Internet
	Удобство сопровождения
	Наличие службы технической поддержки
	Наличие отдельных модулей
	Наличие настроек для инженера
	Наличие настроек для преподавателя
	Наличие настроек для тестируемого
	Портативность
	Наличие сетевой версии				+ (интернет)
	Занимаемый объем					20,8 Мб / 60 Мб

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

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

Рецензенты:

Доррер Г.А., д.т.н., профессор, зав. кафедрой, ФГБОУ ВПО «Сибирский государственный технологический университет», г. Красноярск;

Левшина В.В., д.т.н., профессор, зав. кафедрой управления качеством и математических методов экономики, ФГБОУ ВПО «Сибирский государственный технологический университет», г. Красноярск.

Работа поступила в редакцию 07.05.2013.

Библиографическая ссылка

Горбаченко И.М. ОЦЕНКА КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ СОЗДАНИЯ СИСТЕМ ТЕСТИРОВАНИЯ // Фундаментальные исследования. – 2013. – № 6-4. – С. 823-827;
URL: http://fundamental-research.ru/ru/article/view?id=31642 (дата обращения: 04.03.2019). Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

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

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

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

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

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

Стандартизация характеристик качества

Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методология их оценки. Для определения адекватности качества функционирования, наличия технических возможностей программных средств к взаимодействию, совершенствованию и развитию необходимо использовать стандарты в области оценки характеристик их качества. Основой регламентирования показателей качества программных средств ранее являлся международный стандарт ISO 9126:1991 (ГОСТ Р ИСО / МЭК 9126-93) "Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению". Завершается разработка и формализован последний проект состоящего из четырех частей стандарта ISO 9126-1--4 для замены небольшой редакции 1991 года. Проект состоит из следующих частей под общим заголовком "Информационная технология - характеристики и метрики качества программного обеспечения": "Часть 1. Характеристики и субхарактеристики качества" Часть 2. Внешние метрики качества" "Часть 3. Внутренние метрики качества" "Часть 4. Метрики качества в использовании".

В России в области обеспечения жизненного цикла и качества сложных комплексов программ в основном применяется группа устаревших ГОСТов, которые отстают от мирового уровня на 5-10 лет .

Первая часть стандарта - ISO 9126-1 - распределяет атрибуты качества программных средств по шести характеристикам, используемым в остальных частях стандарта. Исходя из принципиальных возможностей их измерения, все характеристики могут быть объединены в три группы, к которым применимы разные категории метрик:

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

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

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

Вторая и третья части стандарта - ISO 9126-2 и ISO 9126-3 - посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных программных средств. Все таблицы содержат унифицированную рубрикацию, где отражены имя и назначение метрики; метод ее применения; способ измерения, тип шкалы метрики; тип измеряемой величины; исходные данные для измерения и сравнения; а также этапы жизненного цикла программного средства (по ISO 12207), к которым применима метрика.

Четвертая часть стандарта - ISO 9126-4 - предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества программных средств. В ней обосновываются и комментируются выделенные показатели сферы (контекста) использования программных средств и группы выбранных метрик для пользователей.

Выбор показателей качества

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

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

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

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

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

Оценка качества

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

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

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

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

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

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

Оценка защищенности программных средств включает определение полноты использования доступных методов и средств защиты программного средства от потенциальных угроз и достигнутой при этом безопасности функционирования информационной системы. Наиболее широко и детально методологические и системные задачи оценки комплексной защиты информационных систем изложены в трех частях стандарта ISO 15408:1999-1--3 "Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий".

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

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

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

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

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

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

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

Определения характеристик и субхарактеристик качества (ISO 9126-1)

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

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

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

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

Защищенность - способность компонентов программного средства защищать программы и информацию от любых негативных воздействий.

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

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

функциональность,

надёжность,

лёгкость применения,

эффективность,

сопровождаемость,

мобильность.

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

Надежность подробно обсуждалась в первой лекции.

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

Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

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

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

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

2. Обеспечение надёжности - основной мотив разработки программных средств

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

предупреждение ошибок;

самообнаружение ошибок;

самоисправление ошибок;

обеспечение устойчивости к ошибкам.

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

борьбе со сложностью;

обеспечении точности перевода;

преодоления барьера между пользователем и разработчиком;

обеспечения контроля принимаемых решений.

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

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