Файл: Качество продукта и процесса. Этап контроля качества.docx

Скачать файл
Заказать решение

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 05.12.2023

Просмотров: 36

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.



МИНИСТЕРСТВО ПО РАЗВИТИЮ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И КОММУНИКАЦИЙ РЕСПУБЛИКИ УЗБЕКИСТАН

САМАРКАНДСКИЙ ФИЛИАЛ ТАШКЕНТСКОГО УНИВЕРСИТЕТА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ИМЕНИ МУХАММАДА АЛ-ХОРАЗМИ


Самостоятельная работа №1

Тема: Качество продукта и процесса. Этап контроля качества


Группа: DI20-13

Выполнил: Яхёев Н.

Проверила: Бадалова М.Ш.

Самарканд 2023

Т: Качество продукта и процесса. Этап контроля качества

План

  1. Введение

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

  3. Стандарты и модели качества программного обеспечения: Capability Maturity Model (CMM) и ISO/IEC 15504 (SPICE).

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

Введение

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

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

Контроль качества может включать в себя следующие этапы:

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

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

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

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

  5. Тестирование производительности. Это тестирование, которое направлено на проверку производительности продукта и его способности работать с большими объемами данных и пользователей.

  6. Тестирование безопасности. Это тестирование, которое направлено на проверку безопасности продукта и его способности защищать данные пользователей.

  7. Тестирование на соответствие стандартам. Это тестирование, которое направлено на проверку соответствия продукта различным стандартам и требованиям, таким как стандарты качества, безопасности, совместимости и прочие.

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

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

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

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

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

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

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

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

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

Стандарты и модели качества программного обеспечения: Capability Maturity Model (CMM) и ISO/IEC 15504 (SPICE).

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

В начале 90-х годов появились ряд новых стандартов и методологий. Примерами наиболее удачных и содержательных стандартов могут служить

  • Capability Maturity Model (CMM)

  • ISO/IEC 15504 (SPICE).

Capability Maturity Model (1991 год, американский институт программной инженерии SEI при университете Карнеги-Меллон)

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

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

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



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

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

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


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

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

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

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

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


  1. Заинтересованность руководства в данной области (планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т.д.).

  2. Насколько широко данная область применяется в организации (например, оценке в 4 балла соответствует фрагментарное применение).

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

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

К сожалению, использование CMM затрудняют следующие проблемы:

  • стандарт CMM является собственностью Software Engineering Institute и не является общедоступным (в частности, дальнейшая разработка стандарта ведется самим институтом, без заметного влияния остальной части программистского сообщества);

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

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

ISO/IEC 15504 (SPICE) (1991 год, Международная организация по стандартизации инициировала работу по созданию единого стандарта оценки программных процессов)

Стандарт получил имя SPICE (сокращение от Software Process Improvement and Capability Etermination, определение возможностей и улучшение процесса создания программного обеспечения). Официально стандарт называется ISO/IEC 15504: Information Technology - Software Process Assessment и на данный момент существует в качестве рабочей версии, последний выпуск которой состоялся в мае 1998 года.

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

Во время оценки и улучшения качества процессов выполняются следующие задачи:

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

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

  3. Улучшение процесса. После этого весь цикл работ начинается сначала.

Смотрите также файлы