Модель качества программного продукта quest включает. Качество программного обеспечения (Software Quality). Политика организации SQA

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

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

Размещено на 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. Характеристики качества программного обеспечения

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-структура.

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

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

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

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

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

• ISO 9000:2000 Quality management systems - Fundamentals and vocabulary .

  Системы управления качеством - Основы и словарь. (Аналог - ГОСТ Р-2001).

• ISO 9001:2000 Quality management systems - Requirements. Models for quality assurance in design, development, production, installation, and servicing .

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

  Определяет общие правила обеспечения качества результатов во всех процессах жизненного цикла. (Аналог - ГОСТ Р-2001).

  • Этот стандарт выделяет следующие процессы:
    • Управление качеством.
    • Управление ресурсами.
    • Развитие системы управления.
    • Исследования рынка.
    • Проектирование продуктов.
    • Приобретения.
    • Производство.
    • Оказание услуг.
    • Защита продуктов.
    • Оценка потребностей заказчиков.
    • Поддержка коммуникаций с заказчиками.
    • Поддержка внутренних коммуникаций.
    • Управление документацией.
    • Ведение записей о деятельности.
    • Планирование.
    • Обучение персонала.
    • Внутренние аудиты.
    • Оценки управления.
    • Мониторинг и измерения.
    • Управление несоответствиями.
    • Постоянное совершенствование.
    • Управление и развитие системы в целом.
  • Для каждого процесса требуется иметь планы развития процесса, состоящие как минимум из следующих разделов:
    • Проектирование процесса.
    • Документирование процесса.
    • Реализация процесса.
    • Поддержка процесса.
    • Мониторинг процесса.
    • Управление процессом.
    • Усовершенствование процесса.
  • Помимо поддержки и развития системы процессов, нацеленных на удовлетворение нужд заказчиков и пользователей,

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

В дополнение к нему выпущен набор стандартов ISO/IEK 14598, регламентирующий способы оценки этих характеристик. В совокупности они образуют модель качества, известную под названием SQuaRE.

Общий подход заключается в том, чтобы сначала идентифицировать небольшой набор атрибутов качества самого высокого уровня абстракции и затем в направлении «сверху вниз» разбить эти атрибуты на наборы подчиненных атрибутов. Стандарт ISO/IEK 9126 является типичным примером такого подхода.

В рамках модели SQuaRE выделяются следующие 6 основных характеристик качества:

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

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

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

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

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

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

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

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

Билет 26 27

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

Качество исходного кода

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

Читаемость кода

Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости

Низкая сложность кода

Низкое использование ресурсов: памяти и процессорного времени

Корректная обработка исключительных ситуаций

Малое число предупреждений при компиляции и линковке

Методы улучшения качества кода: рефакторинг.

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

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

Некоторые из факторов качества:

понятность

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

Все необходимые части программы должны быть представлены и полностью реализованы.

краткость

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

портируемость

Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.

согласованность

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

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

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

тестируемость

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

удобство использования

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

надёжность

отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок:

структурированность

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

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

Безопасность

ISO 9126 (ГОСТ Р ИСО / МЭК 9126-93) - «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». ISO 9126 это международный стандарт, определяющий оценочные характеристики качества программного обеспечения (далее ПО). Российский аналог стандарта ГОСТ 28195. Стандарт разделяется на 4 части, описывающие следующие вопросы: модель качества; внешние метрики качества; внутренние метрики качества; метрики качества в использовании

Модель качества, установленная в первой части стандарта ISO 9126-1, классифицирует качество ПО в 6-ти структурных наборах характеристик, которые в свою очередь детализированы под-характеристиками(субхарактеристиками), такими как:

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

Пригодностью для применения

Корректностью (правильностью, точностью)

Способностью к взаимодействию (в частности сетевому)

Защищенностью

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

Уровнем завершенности (отсутствия ошибок)

Устойчивостью к дефектам

Восстанавливаемостью

Доступностью

Готовностью

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

Понятностью

Простотой использования

Изучаемостью

Привлекательностью

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

Временной эффективностью

Используемостью ресурсов

Сопровождаемость - Набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций). Детализируется следующими подхарактеристиками (субхарактеристиками):

Удобством для анализа;

Изменяемостью

Стабильностью

Тестируемостью

Мобильность - Набор атрибутов, относящихся к способности ПО быть перенесенным из одного окружения в другое. Детализируется следующими под характеристиками (субхарактеристиками):

Адаптируемостью

Простотой установки (инсталляции)

Сосуществованием (соответствием)

Замещаемостью

Подхарактеристика Соответствие не приведена в вышеописанном списке, но она принадлежит всем характеристикам. Эта характеристика должна отражать отсутствие противоречий с иными стандартами или характеристиками. Например соответствие надежности и практичности.

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

В стандарте выделена модель характеристик качества в использовании. Основными характеристиками качества программных средств (далее ПС) в использовании рекомендуются:

Системная эффективность - "Применения программного продукта по назначению"

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

Безопасность - "Надежность функционирования комплекса программ и возможный риск от его применения для людей, бизнеса и внешней среды"

Удовлетворение требований и затрат пользователей в соответствии с целями применения ПС

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

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

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

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

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

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

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

"усовершенствованием практики" например, является усовершенствование управления конфигурацией программного обеспечения, инспекций, тестирования и т. п.;

ISO 9000 - это совокупность стандартов, декларирующих требования для качественных систем. С точки зрения разработки программного обеспечения наиболее полезны "Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения" ;

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

модель зрелости процесса разработки программного обеспечения - Capability Maturity Model for Software (CMM), предложенная Software Engineering Institute (SEI);

определение возможностей и улучшение процесса создания программного обеспечения. ISO/IEC 15504 Software Process Improvement and Capability determination (SPICE).

Два важнейших утверждения лежат в основе достижения качества.

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

Подходы к достижению качества таковы:

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

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

В настоящее время не существует общепринятых критериев качества программного обеспечения.

Стандарт ISO 9000-3, п. 6.4.1

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

Современные стандарты уточняют понятие качества, вводя совокупность черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. Перечислим ряд таких характеристик [Жоголев 1996].

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

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

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

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

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

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

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

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

Существуют следующие подходы по обеспечению надежности:

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

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

Количественные критерии, связанные с различными способами оценки (метриками) сложности программ. Укажем примеры численных характеристик.

Меры Холстеда [Холстед 1981], включающие ряд формул, оценивающих длину, объем, уровень и интеллектуальное содержание программ.

Оценка сложности управляющего графа программы. Фрагмент программы может быть оценен цикломатическим числом ее управляющего графа, которое равно m - n + 2, где m - число дуг, an - число вершин управляющего графа. Считается, что цикломатическое число не должно превышать 10.

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

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

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

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

Оценка качества процесса разработки

Требовать и эффективности и гибкости от одной и той же программы -

все равно, что искать очаровательную и скромную жену.

По-видимому, нам следует остановиться на чем-то одном из двух.

Д. Вейнберг

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

• Оценить качество конечного продукта.
• Оценить качество процесса разработки.

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

Модель зрелости процесса разработки программного обеспечения

В модели определено пять уровней зрелости организации (http://www.sei.cmu.edu/cmm).

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

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

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

Управляемый уровень. В компании устанавливаются детальные количественные показатели на процесс разработки и качество продукта. И процесс разработки, и продукты - понимаемы и контролируемы.

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

Определение возможностей и улучшение процесса создания программного обеспечения

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

Уровень 0. Процесс не выполняется.

Уровень 1. Выполняемый процесс.

Уровень 2. Управляемый процесс.

Уровень 3. Установленный процесс.

Уровень 4. Предсказуемый процесс.

Уровень 5. Оптимизирующий процесс.

Во время оценки и улучшения качества процессов выполняются задачи [Терехов, Туньон 1999], описанные ниже.

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

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

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

О роли министерства обороны

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

"Достаточно хорошее" программное обеспечение

Вчера в Сиэтле после упоминания Биллом Гейтсом о выходе бета-версии

новой программы компании Microsoft произошло землетрясение.

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

Пропагандистом "достаточно хорошего" программного обеспечения является Эдвард Йордон [Йордон 2001]. Подчеркнем, что он применяет это понятие к "безнадежным проектам", которые связаны жесткими ограничениями на время, бюджет и людские ресурсы (см. разд. 1.6). В большинстве безнадежных проектов заказчик может быть удовлетворен системой, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями, достаточно устойчива и будет готова достаточно скоро. Фактически, эти характеристики можно считать определением "достаточно хорошего" программного обеспечения.

Оказывается, что даже "достаточно хорошее" программное обеспечение создать сложно. Приведем часть из совокупности причин, дающих этому объяснение [Йордон 2001].

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

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

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

Джеймс Бах (James Bach) указывает следующие необходимые условия для создания "достаточно хорошего" программного обеспечения:

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

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

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

Стандартизация информационных технологий

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

Стандарты можно классифицировать следующим образом:

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

Процесс стандартизации информационных технологий поддерживают три основные группы организаций. Международные организации, входящие в структуру ООН. International Organization for Standardization (ISO) - международная организация по стандартизации.

Об ISO

В 1947 году представители 25 стран решили создать организацию, основной задачей которой стала бы координация разработок и унификация международных стандартов. Новая организация получила название International Organization for Standardization (ISO). Несоответствие полного названия и аббревиатуры объясняется тем, что "ISO" - это греческий префикс, означающий "равный".

International Electrotechnical Commision (IEC) - международная электротехническая комиссия.

International Telecommunication Union-Telecommunications (ITU-T) - международный союз по телекоммуникации - телекоммуникация. До 1993 года эта организация называлась International Telegraph and Telephone Consultative Committee - международный консультативный комитет по телефонии и телеграфии.

Промышленные профессиональные или административные организации.

Institute of Electrical and Electronic Engineers (IEEE) - институтинженеровпоэлектротехникеиэлектронике.

Internet Activity Board (IAB) - совет управления деятельностью Интернета.

Промышленные консорциумы.

Object Management Group (OMG) - группа управления объектами.

Х/Open - консорциум, организованный группой поставщиков компьютерной техники.

Open Software Foundation (OSF) - фонд открытого программного обеспечения.

В 1987 году ISO и IEC объединили свою деятельность в области стандартизации информационных технологий и создали единый орган - Joint Technical Committee 1 (JTC1) - объединенный технический комитет 1. Этот комитет предназначен для формирования системы базовых стандартов з области информационных технологий.

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

Электронное пособие Карпович Е.Е.

Введение. 1

1. Программное обеспечение как промышленная продукция. 2

1.1 Основные понятия. 2

1.2. Характеристики качества программного обеспечения. 3

2. Жизненный цикл программного обеспечения. 5

2.1. Понятие жизненного цикла программного обеспечения. 5

2.2. Процессы жизненного цикла программного обеспечения. 6

2.3. Модели жизненного цикла программного обеспечения. 11

2.4. Стратегии проектирования программного обеспечения. 15

3. Методологии разработки программного обеспечения. 19

3.1 Структурный подход к разработке программного обеспечения. 19

3.2 Модульное программирование. 22

3.3. Объектно-ориентированный подход к разработке программного обеспечения. 31

3.3. Методология визуального программирования. 33

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

4.1. Общие положения. 34

4.2. Цели и задачи. Основные определения. 34

4.3. Организация процесса тестирования программного обеспечения 35

4.4. Стратегии тестирования программного обеспечения. 36

4.5. Уровни тестирования программного обеспечения. 38

5. Документирование программного обеспечения. 39

5.1. Общие положения. 39

5.2. Программа и методика испытаний. 39

5.3. Описание программы.. 40

5.4. Пояснительная записка. 41

5.5. Текст программы.. 42

5.6. Описание применения. 42

5.7. Руководство системного программиста. 42

5.8. Руководство программиста. 43

5.9. Руководство оператора. 43

Литература. 44

Введение

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

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

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

Цель дисциплины «Методология разработки программного обеспечения» – научить студентов основным принципам конструирования программного обеспечения, ознакомить с концепциями, методологиями разработки, тестирования и документирования программного обеспечения.

Программное обеспечение как промышленная продукция

Основные понятия

Принято выделять семь видов обеспечения вычислительных систем:

· математическое;

· лингвистическое;

· информационное;

· программное;

· техническое;

· методическое;

· организационное.

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

Под программой будем понимать:

1) совокупность кода и данных, пригодных для исполнения процессорам (исполняемая программа);

2) самостоятельный компонент относительно небольшого размера, пред­назначенный для решения локальной задачи (программа как компонент сис­темы).

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

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

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

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

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

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

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

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

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

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

Функциональность;

Надежность;

Легкость применения;

Эффективность;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модифицируемость: расширяемость, модифицируемость (в узком смысле, как примитив качества), структурированность, модульность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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