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

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

Качество ПО является предметом стандартизации. Согласно ГОСТ 2844-94 качество ПО есть совокупность свойств (показателей качества) ПО, которые обеспечивают его способность удовлетворять потребности заказчика в соответствии с его назначением. Этот стандарт регламентирует базовую модель качества и показатели, главным среди которых является надежность. Стандарт 180/1ЕС12207 опре-

Рис. 9.1.

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

Согласно этому стандарту на всех этапах ЖЦ разработки ПО должен проводиться следующий контроль качества ПО:

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

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

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

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

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

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

Качество ПО характеризуется тремя аспектами: качеством ПП, качеством процессов ЖЦ и качеством сопровождения или внедрения (рис. 9.2).

Качество Качество Качество

процесса продукта сопровождения

Рис. 9.2.

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

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

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

Первый уровень соответствует определению характеристик (показателей) качества ПО, каждая из которых отражает отдельную точку зрения пользователя на качество. Согласно существующим стандартам (ISO/IEC9126, ДСТУ 2844-1994, ДСТУ 2850-1994, ДСТУ 3230-1995) в модель качества входит шесть характеристик или шесть показателей качества (рис. 9.3): функциональность (functionality), надежность (realibility), удобство (usability), эффективность (efficiency), сопровождаемость (maitainnability), переносимость (portability).

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

Третий уровень предназначен для измерения качества с помощью метрик, каждая из которых, согласно стандарту 1SO/IEC9126, определяется как комбинация метода измерения атрибута и шкалы измерения его значений. Для оценки атрибутов качества на этапах ЖЦ ПО (при просмотре документации и программ, а также результатов тестирования программ) используются метрики с заданным оценоч-

Показатели-характеристики

Атрибуты

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

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

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

Рассмотрим более подробно показатели качества ПО.

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

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

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

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

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

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

К подхарактеристикам (субхарактеристикам) надежности ПО относятся следующие.

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

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

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

К некоторым типам «критических систем» (реального времени, радарных, систем безопасности, коммуникаций и др.) предъявляются требования по обеспечению высокой надежности (недопустимость ошибок, точность, достоверность, удобство применения и др.). Надежность ПО в значительной степени зависит от числа оставшихся и неустраненных ошибок в процессе его разработки на этапах ЖЦ. В ходе эксплуатации ошибки обнаруживаются и устраняются. Если при исправлении ошибок не вносятся новые или, по крайней мере, новых ошибок вносится меньше, чем устраняется, то в ходе эксплуатации надежность ПО непрерывно возрастает. Чем интенсивнее проводится эксплуатация, тем интенсивнее выявляются ошибки и быстрее растет надежность ПО.

На надежность ПО влияют следующие факторы:

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

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

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

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

в процессе эксплуатации, а также современных моделей надежности;

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

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

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

• готовностью к использованию (availability);
• готовностью к непрерывному функционированию (reliability);
• безопасностью для окружающей среды, т.е. способностью системы не вызывать катастрофических последствий в случае отказа (safety);
• секретностью и сохранностью информации (confidential);
• способностью к сохранению системы и устойчивости к самопроизвольному ее изменению (integrity);
• способностью к эксплуатации ПО, простотой выполнения операций обслуживания, а также устранения ошибок, восстановлением системы после их устранения (maintainability);
• готовностью и сохранностью информации (security) и др. Достижение надежности системы обеспечивается предотвращением отказа (fault prevention) или его устранением (removal fault), а также оценкой возможности появления новых отказов и мер борьбы с ними.

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

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

Р{ Т > пЬ} = (1 - Л.) И, где Л. - вероятность отказа, при этом среднее

время ожидания будет равно Т = -.

Положим, что значение 5 уменьшается, а время Т остается фиксированным, тогда имеем

R{T>t} =

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

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

Удобство применения. Этот показатель характеризуется множеством атрибутов, определяющих необходимые пригодные условия использования ПО (например, диалоговое, недиалоговое) заданным кругом пользователей для получения соответствующих результатов. В стандарте ДСТУ 2850-1994 удобство применения определено как множество атрибутов ПП, характеризующих его эргономичность:

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

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

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

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

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

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

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

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

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

Параметры качества ПО

Основные характеристики качества программного обеспечения согласно стандарту ISO/IEC 25010:2011:

1. Функциональность. ПО признается функциональным, если выполняет возложенные на него задачи, отвечает заданным потребностям пользователей. Данный аспект предполагает правильную и точную работу, совместимость всех входящих в состав компонентов.
2. Надежность. Под надежностью ПО понимают бесперебойное выполнение возлагаемых на него задач на заданных условиях в течение установленного времени.
3. Юзабилити (удобство использования). Этот параметр характеризует степень удобства ПО для пользователей, его наглядность, легкость эксплуатации и изучения.
4. Эффективность. Параметру соответствует степень обеспечения продуктом необходимой производительности при заданных условиях.
5. Удобство сопровождения. Этот показатель характеризует простоту анализа, тестирования, коррекции компонентов ПО, его обслуживания, а также степень адаптации к новым условиям.
6. Портативность. Степень легкости его переноса на другую платформу. Обеспечение качества ПО предполагает его проверку по каждому из перечисленных параметров, выявление слабых сторон и устранение неисправностей.
7. Совместимость. Способность программных компонентов взаимодействовать друг с другом.
8. Защищенность, т.е. минимизация угроз, связанных с несанкционированным чтением, изменением информации и т. д. Угрозы могут быть также связаны с некорректным использованием ПО, внешним воздействием со стороны посторонних лиц, выходом из строя технических средств.

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

Термины «тестирование» и «обеспечение качества», безусловно, связаны между собой, но не тождественны. В чем же различие?

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

В задачи QA-специалистов входит:

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

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

Таким образом, вы видите, что обеспечение качества – более широкое понятие, которое включает в себя работы по тестированию.

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

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

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

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

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

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

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

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

хорошую работу на сайт">

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аутсорсинг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Capability Maturity Model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

Методологии Сопутствующие дисциплины

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

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

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

• Читаемость кода
• Лёгкость поддержки, тестирования , отладки, исправления ошибок, изменения и портируемости
• Низкая сложность кода
• Низкое использование ресурсов: памяти и процессорного времени
• Корректная обработка исключительных ситуаций
• Малое число предупреждений при компиляции и линковке

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

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

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

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

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

С точки зрения пользователя

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

• Является ли пользовательский интерфейс интуитивно понятным?
• Насколько просто выполнять простые, частые операции?
• Насколько легко выполняются сложные операции?
• Выдаёт ли программа понятные сообщения об ошибках?
• Всегда ли программа ведёт себя так как ожидается?
• Имеется ли документация и насколько она полна?
• Является ли интерфейс пользователя само-описательным/само-документирующим?
• Всегда ли задержки с ответом программы являются приемлемыми?

См. также

Ссылки

Разработка программного обеспечения
Известные деятели
Процесс
Концепции
Направления
Модели разработки
Другие модели
Прочее

Wikimedia Foundation . 2010 .

Смотреть что такое "Качество программного обеспечения" в других словарях:

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

Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия

Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия

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

Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия

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

Характеристики программного продукта, которые: позволяют минимизировать усилия пользователей по подготовке исходных данных, применению программного продукта и оценке полученных результатов, а также позволяют вызывать положительные эмоции… … Финансовый словарь

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

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

Книги

• Совершенный код: Практическое руководство по разработке программного обеспечения , Макконнелл С.. Более 10 лет первое издание этой книги считалось одним из лучших практических руководств по программированию. Сейчас эта книга полностью обновлена с учетом современных тенденций и технологий…