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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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