Руководство по управлению для его хорошем качестве

Управление качеством программного обеспечения – Введение

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

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

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

• Software Quality Assurance – Software Quality Assurance (SQA) – это комплекс мероприятий, направленных на обеспечение качества процессов разработки программного обеспечения, которые в конечном итоге приводят к качественным программным продуктам. Деятельность устанавливает и оценивает процессы, которые производят продукты. Это включает процессно-ориентированные действия.

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

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

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

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

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

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

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

Сложность продукта

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

Видимость продукта

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

Разработка продукта и производственный процесс

В промышленном продукте дефекты могут быть обнаружены на следующих этапах –

• Разработка продукта – На этом этапе проектировщики и сотрудники отдела обеспечения качества (QA) проверяют и тестируют прототип продукта для выявления его дефектов.

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

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

Разработка продукта – На этом этапе проектировщики и сотрудники отдела обеспечения качества (QA) проверяют и тестируют прототип продукта для выявления его дефектов.

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

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

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

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

Характеристика	Программные продукты	Другие промышленные товары
сложность	Миллионы вариантов работы	тысяча вариантов работы
видимость продукта	Невидимый продукт Трудно обнаружить дефекты в лицо	Видимый продукт Эффективное обнаружение дефектов визуально
Характер разработки и производственного процесса	могут дефекты только в одной фазе	может обнаружить дефекты на всех следующих этапах Разработка продукта Планирование производства продукции производство

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

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

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

Несколько моделей факторов качества программного обеспечения и их категоризация были предложены за эти годы. Классическая модель факторов качества программного обеспечения, предложенная McCall, состоит из 11 факторов (McCall et al., 1977). Аналогично, модели, состоящие из 12-15 факторов, были предложены Дойчем и Уиллисом (1988) и Эвансом и Марсиниаком (1987).

Все эти модели существенно не отличаются от модели Маккола. Факторная модель Макколла предоставляет практичный, современный метод классификации требований к программному обеспечению (Pressman, 2000).

Модель Фактора Маккола

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

• Факторы работы продукта – правильность, надежность, эффективность, целостность, удобство использования.

• Факторы пересмотра продукта – ремонтопригодность, гибкость, тестируемость.

• Факторы перехода продукта – Переносимость, Возможность повторного использования, Совместимость.

Факторы работы продукта – правильность, надежность, эффективность, целостность, удобство использования.

Факторы пересмотра продукта – ремонтопригодность, гибкость, тестируемость.

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

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

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

правильность

Эти требования касаются правильности вывода программного обеспечения системы. Они включают в себя –

• Выходная миссия

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

• Полнота выводимой информации, на которую могут повлиять неполные данные.

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

• Доступность информации.

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

Выходная миссия

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

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

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

Доступность информации.

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

надежность

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

КПД

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

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

целостность

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

Юзабилити

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

Факторы качества редакции продукта

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

Ремонтопригодность

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

гибкость

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

способность быть свидетелем в суде

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

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

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

портативность

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

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

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

Interoperability

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

SQA Компоненты

Software Quality Assurance (SQA) – это комплекс мероприятий по обеспечению качества в процессах разработки программного обеспечения. Это гарантирует, что разработанное программное обеспечение соответствует и соответствует определенным или стандартизированным спецификациям качества. SQA – это непрерывный процесс в рамках жизненного цикла разработки программного обеспечения (SDLC), который регулярно проверяет разработанное программное обеспечение, чтобы убедиться, что оно соответствует требуемым показателям качества.

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

Включает в себя следующие виды деятельности –

• Определение и реализация процесса
• Аудиторская проверка
• Повышение квалификации

Процессы могут быть –

• Методология разработки программного обеспечения
• Управление проектом
• Управление конфигурацией
• Разработка требований / Управление
• Предварительный расчет
• Разработка программного обеспечения
• Тестирование и др.

После того, как процессы определены и внедрены, Контроль качества выполняет следующие обязанности:

• Выявить слабые места в процессах
• Исправьте эти недостатки, чтобы постоянно улучшать процесс

Компоненты системы SQA

Система SQA всегда сочетает в себе широкий спектр компонентов SQA. Эти компоненты могут быть классифицированы на следующие шесть классов –

Предпроектные компоненты

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

Компоненты оценки жизненного цикла проекта

Жизненный цикл проекта состоит из двух этапов: этап жизненного цикла разработки и этап эксплуатации-обслуживания.

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

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

Компоненты инфраструктуры предотвращения и улучшения ошибок

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

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

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

Компоненты стандартизации, сертификации и оценки системы SQA

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

Организация для SQA – человеческие компоненты

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

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

Эти компоненты помогают улучшить предварительные шаги, предпринятые перед началом проекта. Включает в себя –

• Обзор контракта
• Планы развития и качества

Обзор контракта

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

В частности, действия по рассмотрению контракта включают в себя –

• Разъяснение требований заказчика

• Обзор графика проекта и сметных потребностей

• Оценка способности профессионального персонала выполнять предложенный проект

• Оценка способности клиента выполнять свои обязательства

• Оценка рисков развития

Разъяснение требований заказчика

Обзор графика проекта и сметных потребностей

Оценка способности профессионального персонала выполнять предложенный проект

Оценка способности клиента выполнять свои обязательства

Оценка рисков развития

Планы развития и качества

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

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

Основные вопросы, рассматриваемые в плане развития проекта:

• Расписание
• Требуемые людские и аппаратные ресурсы
• Оценка рисков
• Организационные вопросы: члены команды, субподрядчики и партнерства
• Методология проекта, инструменты разработки и др.
• Планы повторного использования программного обеспечения

Основные вопросы, рассматриваемые в плане качества проекта:

• Цели в области качества, выраженные в соответствующих измеримых терминах

• Критерии начала и окончания каждого этапа проекта

• Списки обзоров, тестов и других запланированных действий по проверке и валидации

Цели в области качества, выраженные в соответствующих измеримых терминах

Критерии начала и окончания каждого этапа проекта

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

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

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

• Метрики продукта – описывает характеристики продукта, такие как размер, сложность, особенности дизайна, производительность и уровень качества.

• Метрики процесса – эти характеристики могут использоваться для улучшения деятельности по разработке и сопровождению программного обеспечения.

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

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

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

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

Некоторые показатели относятся к нескольким категориям. Например, показатели качества процесса в проекте являются как показателями процесса, так и показателями проекта.

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

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

• Метрики качества продукции
• Показатели качества в процессе
• Метрики качества обслуживания

Метрики качества продукции

Эти показатели включают в себя следующее –

• Среднее время до отказа
• Плотность дефектов
• Проблемы с клиентами
• Удовлетворенность клиентов

Среднее время до отказа

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

Плотность дефектов

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

Проблемы с клиентами

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

Метрика проблем обычно выражается в виде проблем за месяц пользователя (PUM) .

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Куда,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

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

Удовлетворенность клиентов

Удовлетворенность клиентов часто измеряется данными опросов клиентов по пятибалльной шкале –

• Очень доволен
• Довольный
• нейтральный
• неудовлетворенный
• Очень Недовольный

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

• Процент полностью удовлетворенных клиентов
• Процент довольных клиентов
• Процент недовольных клиентов
• Процент неудовлетворенных клиентов

Обычно этот процент удовлетворения используется.

Показатели качества в процессе

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

• Плотность дефектов при машинном тестировании
• Схема прибытия дефекта во время машинного тестирования
• Схема устранения дефектов на основе фазы
• Эффективность устранения дефектов

Плотность дефектов при машинном тестировании

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

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

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

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

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

• Образец действительных дефектов прибывает, когда определение проблемы сделано на сообщенных проблемах. Это истинный образец дефекта.

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

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

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

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

Схема устранения дефектов на основе фазы

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

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

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

Эффективность устранения дефектов

Это можно определить следующим образом:

DRE= fracДефектудаленвовремяadevelopmentphaseДефектыскрытыйintheproduct times100%

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

Метрики качества обслуживания

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

• Исправить отставание и индекс управления отставанием
• Исправьте время отклика и исправьте реакцию
• Проценты по просроченным платежам
• Исправить качество

Исправить отставание и индекс управления отставанием

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

Индекс управления отставанием (BMI) используется для управления отставанием от открытых и нерешенных проблем.

BMI= fracЧислоofпроблемызакрытовтечениемесяцЧислоизпроблемприбыловтечениемесяц раз100%

Если ИМТ больше 100, это означает, что отставание уменьшается. Если ИМТ меньше 100, то отставание увеличивается.

Исправьте время отклика и исправьте реакцию

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

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

Проценты по просроченным платежам

Он рассчитывается следующим образом –

PercentDelinquentFixes=

 fracNumberofисправляетчтопревышеноответвремякритериипоceveritylevelNumberofисправленодоставленоinaуказановремя times100%

Исправить качество

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

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

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

Основы измерения

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

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

Измерение в повседневной жизни

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

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

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

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

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

Измерение в программной инженерии

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

Для большинства проектов развития,

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

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

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

• Чтобы понять, что происходит во время разработки и обслуживания
• Контролировать, что происходит в проекте
• Чтобы улучшить процессы и цели

Репрезентативная теория измерения

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

Эмпирические отношения

В реальном мире мы понимаем вещи, сравнивая их, а не присваивая им цифры.

Например, для сравнения высоты мы используем термины «выше чем», выше чем. Таким образом, эти «выше, чем», выше, чем эмпирические отношения для высоты.

Мы можем определить более одного эмпирического отношения на одном наборе.

Например, X выше, чем Y. X, Y намного выше, чем Z.

Эмпирические отношения могут быть одинарными, двоичными, троичными и т. Д.

X высокий, Y не высокий одинарные отношения.

X выше, чем Y – бинарное отношение.

Эмпирические отношения в реальном мире могут быть сопоставлены с формальным математическим миром. В основном эти отношения отражают личные предпочтения.

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

Шкала Лайкерта

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

Например – Это программное обеспечение работает хорошо.

Полностью согласен	Согласен	Ни согласен, ни несогласен	не соглашаться	Сильно не согласен

Принудительный рейтинг

Порядок заданных альтернатив от 1 (лучший) до n (худший).

Например: ранжируйте следующие 5 программных модулей в соответствии с их производительностью.

Наименование модуля	Ранг
Модуль А
Модуль Б
Модуль С
Модуль D
Модуль Е

Вербальная частотная шкала

Например – Как часто эта программа дает сбой?

Всегда	Часто	Иногда	Редко	Никогда

Порядковый масштаб

Здесь пользователям будет предоставлен список альтернатив, и они должны выбрать один.

Например – Как часто эта программа дает сбой?

• почасовой
• Ежедневно
• еженедельно
• ежемесячно
• Несколько раз в год
• Один или два раза в год
• Никогда

Сравнительная шкала

Здесь пользователь должен дать число, сравнивая различные варианты.

Очень высокий О том же Очень низкий

1 2 3 4 5 6 7 8 9 10

Числовой масштаб

Здесь пользователь должен указать число в соответствии с его важностью.

Неважно Важно

1 2 3 4 5 6 7 8 9 10

Правила отображения

Чтобы выполнить сопоставление, мы должны указать домен, диапазон, а также правила для выполнения сопоставления.

Например – Домен – Реальный мир

• Диапазон – математический мир, такой как целые числа, действительные числа и т. Д.

• Правила – Для измерения высоты, обувь носить или нет

Диапазон – математический мир, такой как целые числа, действительные числа и т. Д.

Правила – Для измерения высоты, обувь носить или нет

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

Репрезентативное условие измерения

Условие представления утверждает, что отображение измерений (M) должно отображать объекты в числа, а эмпирические отношения в числовые отношения таким образом, чтобы эмпирические отношения сохранялись и сохранялись посредством числовых отношений.

Например: эмпирическое отношение «выше чем» отображается в числовое отношение «>», т. Е. X выше, чем Y, если и только если M (X)> M (Y)

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

Для унарного отношения «высокий» мы могли бы иметь числовое отношение

X> 50

Условие представления требует, чтобы для любой меры М ,

Х высокий тогда и только тогда, когда М (Х)> 50

Ключевые этапы формальных измерений

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

Измерение и модели

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

Измерение бывает двух типов –

• Прямое измерение
• Косвенное измерение

Прямое измерение

Это измерения, которые могут быть измерены без участия какого-либо другого объекта или атрибута.

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

• Длина исходного кода по LOC
• Продолжительность цели тестирования по истекшему времени
• Количество дефектов, обнаруженных в процессе тестирования путем подсчета дефектов
• Время, которое программист тратит на программу

Косвенные измерения

Это измерения, которые могут быть измерены с точки зрения любого другого объекта или атрибута.

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

 smallProgrammerПроизводительность= fracLOCпроизведеноЧеловекмесяцыизусилия

 smallМодульДефектПлотность= fracЧислоofдефектовМодульразмер

 smallDefectDetectionEfficiency= fracNumberofдефектовобнаруженоВсегочислоofдефектов

 smallТребованиеСтабильность= fracЧислоofисходныйтребованияИтогочислоofтребований

 smallTestэффективностькоэффициент= fracчислоизпредметовпокрытыйвсегочислоизпредметов

 smallSystemspoilage= fracУсилиепотраченонаисправлениенеисправностиИтогопроектусилие

Измерение для прогноза

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

Весы измерения

Шкалы измерения – это отображения, используемые для представления эмпирической системы отношений. В основном это 5 типов –

• Номинальная шкала
• Порядковый масштаб
• Интервальная шкала
• Масштаб отношения
• Абсолютная шкала

Номинальная шкала

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

У него есть две основные характеристики –

• Эмпирическая система отношений состоит только из разных классов; среди классов нет понятия упорядоченности.

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

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

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

Порядковый масштаб

Он размещает элементы в упорядоченной схеме классификации. Он имеет следующие характеристики –

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

• Любое отображение, которое сохраняет порядок, является приемлемым.

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

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

Любое отображение, которое сохраняет порядок, является приемлемым.

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

Интервальная шкала

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

Он имеет следующие характеристики –

• Это сохраняет порядок как порядковый масштаб.

• Это сохраняет различия, но не соотношение.

• Сложение и вычитание могут быть выполнены в этом масштабе, но не умножение или деление.

Это сохраняет порядок как порядковый масштаб.

Это сохраняет различия, но не соотношение.

Сложение и вычитание могут быть выполнены в этом масштабе, но не умножение или деление.

Если атрибут измерим в интервальной шкале, а M и M ‘ являются отображениями, которые удовлетворяют условию представления, то мы всегда можем найти два числа a и b, таких что,

M = aM ‘+ b

Масштаб отношения

Это самая полезная шкала измерений. Здесь существует эмпирическое отношение для определения коэффициентов. Он имеет следующие характеристики –

• Это отображение измерений, которое сохраняет порядок, размер интервалов между объектами и соотношение между объектами.

• Существует нулевой элемент, представляющий полное отсутствие атрибутов.

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

• Все арифметические операции могут быть применены.

Это отображение измерений, которое сохраняет порядок, размер интервалов между объектами и соотношение между объектами.

Существует нулевой элемент, представляющий полное отсутствие атрибутов.

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

Все арифметические операции могут быть применены.

Здесь отображение будет иметь вид

M = aM ‘

Где «а» – это положительный скаляр.

Абсолютная шкала

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

Он имеет следующие характеристики –

• Измерение производится путем подсчета количества элементов в наборе сущностей.

• Атрибут всегда принимает форму «количество вхождений x в сущности».

• Существует только одно возможное отображение измерений, а именно фактическое количество.

• Все арифметические операции могут быть выполнены с результирующим счетом.

Измерение производится путем подсчета количества элементов в наборе сущностей.

Атрибут всегда принимает форму «количество вхождений x в сущности».

Существует только одно возможное отображение измерений, а именно фактическое количество.

Все арифметические операции могут быть выполнены с результирующим счетом.

Эмпирические исследования

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

• Выбор метода расследования
• Изложение гипотезы
• Поддержание контроля над переменной
• Делать расследование значимым

Выбор методики расследования

Ключевые компоненты эмпирического исследования в разработке программного обеспечения –

• Опрос
• Тематическое исследование
• Формальный эксперимент

Опрос

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

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

Тематическое исследование

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

Формальный эксперимент

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

Конкретный метод расследования может быть выбран в соответствии со следующими рекомендациями –

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

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

• Если репликация невозможна на более высоких уровнях, то эксперимент невозможен.

• Если стоимость репликации низкая, то мы можем рассмотреть эксперимент.

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

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

Если репликация невозможна на более высоких уровнях, то эксперимент невозможен.

Если стоимость репликации низкая, то мы можем рассмотреть эксперимент.

Изложение гипотезы

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

Поддержание контроля над переменными

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

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

Например, если мы хотим определить, может ли изменение языка программирования повлиять на производительность проекта, тогда этот язык будет переменной состояния. Предположим, что в настоящее время мы используем FORTRAN, который мы хотим заменить на Ada. Тогда FORTRAN будет контрольным языком, а Ada – экспериментальным.

Делать расследование значимым

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

Соответствующие теории и общепринятая мудрость

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

Изучение отношений

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

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

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

Оценка точности моделей

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

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

Валидационные меры

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

Измерение программного обеспечения

Основа для измерения программного обеспечения основана на трех принципах:

• Классификация объектов, подлежащих проверке
• Определение соответствующих целей измерения
• Определение уровня зрелости, которого достигла организация

Классификация сущностей, подлежащих проверке

В программной инженерии существует в основном три класса сущностей. Они –

• Процессы
• Товары
• Ресурсы

Все эти объекты имеют как внутренние, так и внешние объекты.

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

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

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

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

Различные атрибуты, которые могут быть измерены для каждого из объектов, следующие:

Процессы

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

• Продолжительность процесса или одного из его действий

• Усилия, связанные с процессом или одним из его видов деятельности

• Количество инцидентов определенного типа, возникающих в ходе процесса или одного из его действий

Продолжительность процесса или одного из его действий

Усилия, связанные с процессом или одним из его видов деятельности

Количество инцидентов определенного типа, возникающих в ходе процесса или одного из его действий

Различные внешние атрибуты процесса – это стоимость, управляемость, эффективность, качество и стабильность.

Товары

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

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

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

Ресурсы

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

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

Определение соответствующих целей измерения

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

Парадигма цель-вопрос-метрика (GQM)

Подход GQM обеспечивает структуру, включающую следующие три этапа:

• Перечисление основных целей проекта разработки или сопровождения

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

• Решите, что должно быть измерено, чтобы иметь возможность адекватно отвечать на вопросы

Перечисление основных целей проекта разработки или сопровождения

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

Решите, что должно быть измерено, чтобы иметь возможность адекватно отвечать на вопросы

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

Типичные цели выражаются с точки зрения производительности, качества, риска, удовлетворенности клиентов и т. Д. Цели и вопросы должны строиться с точки зрения их аудитории.

Чтобы составить цели, вопросы и показатели, Basili & Rombach предоставили серию шаблонов.

• Цель – Чтобы (охарактеризовать, оценить, предсказать, мотивировать и т. Д.) (Процесс, продукт, модель, метрика и т. Д.), Чтобы понять, оценить, управлять, спроектировать, выучить, улучшить и т. Д. Пример : охарактеризовать продукт для того, чтобы выучить его.

• Перспектива – Изучите (стоимость, эффективность, правильность, дефекты, изменения, показатели продукта и т. Д.) С точки зрения разработчика, менеджера, клиента и т. Д. Пример . Изучите дефекты с точки зрения заказчика.

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

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

Перспектива – Изучите (стоимость, эффективность, правильность, дефекты, изменения, показатели продукта и т. Д.) С точки зрения разработчика, менеджера, клиента и т. Д. Пример . Изучите дефекты с точки зрения заказчика.

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

Измерение и улучшение процесса

Обычно измерение полезно для –

• Понимание процесса и продуктов
• Установление базовой линии
• Доступ и прогнозирование результата

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

Уровень 1: Ad hoc

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

Уровень 2: Повторяемый

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

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

Уровень 3: Определен

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

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

Уровень 4: Управляемый

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

Уровень 5: Оптимизация

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

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

Определение уровня зрелости

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

• На уровне 1 , проект, вероятно, будет иметь плохо определенные требования. На этом уровне измерение характеристик требований затруднено.

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

• На уровне 3 промежуточные действия определяются с критериями входа и выхода для каждого действия

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

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

На уровне 3 промежуточные действия определяются с критериями входа и выхода для каждого действия

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

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

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

Проверка правильности измерения программного обеспечения системы включает в себя два этапа –

• Валидация измерительных систем
• Валидация систем прогнозирования

Валидация измерительных систем

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

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

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

m (P1 + P2) = m (P1) + m (P2)

Если программа P1 имеет большую длину, чем программа P2 , то любая мера m также должна удовлетворять:

м (Р1)> м (Р2)

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

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

Валидация систем прогнозирования

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые показатели относятся к нескольким категориям. Например, показатели качества процесса в проекте являются как показателями процесса, так и показателями проекта.

Объем программных метрик

Метрики программного обеспечения содержат много действий, которые включают следующее –

• Оценка затрат и усилий
• Меры и модель производительности
• Сбор информации
• Количественные модели и меры
• Надежность моделей
• Модели производительности и оценки
• Структурные и сложные показатели
• Способность – оценка зрелости
• Управление по метрикам
• Оценка методов и инструментов

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

Оценка стоимости и усилий

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

• Модель Бома КОКОМО
• Тонкая модель Путнэма
• Функциональная точечная модель Альбрехта

Модель и меры производительности

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

Сбор информации

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

Качественные модели и меры

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

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

Модели надежности

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

Оценка производительности и модели

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

Структурные и Сложность Метрики

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

Оценка зрелости

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

Управление метриками

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

Оценка методов и инструментов

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

Манипуляция данными

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

Что такое хорошие данные?

Собранные данные можно рассматривать как хорошие данные, если они могут дать ответы на следующие вопросы:

• Они правы? – Данные могут считаться правильными, если они были собраны в соответствии с точными правилами определения метрики.

• Они точны? – Точность относится к разнице между данными и фактическим значением.

• Они точно точны? – Точность связана с количеством десятичных знаков, необходимых для выражения данных.

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

• Связаны ли они с определенной деятельностью или периодом времени? – Если данные связаны с определенной деятельностью или периодом времени, то они должны быть четко указаны в данных.

• Могут ли они быть воспроизведены? – Обычно такие исследования, как опросы, тематические исследования и эксперименты, часто повторяются при разных обстоятельствах. Следовательно, данные также должны быть легко воспроизведены.

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

Они точны? – Точность относится к разнице между данными и фактическим значением.

Они точно точны? – Точность связана с количеством десятичных знаков, необходимых для выражения данных.

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

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

Могут ли они быть воспроизведены? – Обычно такие исследования, как опросы, тематические исследования и эксперименты, часто повторяются при разных обстоятельствах. Следовательно, данные также должны быть легко воспроизведены.

Как определить данные?

Данные, которые собираются для целей измерения, бывают двух типов:

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

• Уточненные данные – уточненные данные получаются в результате извлечения основных элементов данных из необработанных данных для получения значений атрибутов.

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

Уточненные данные – уточненные данные получаются в результате извлечения основных элементов данных из необработанных данных для получения значений атрибутов.

Данные могут быть определены в соответствии со следующими пунктами –

• Место нахождения
• тайминг
• симптомы
• Конечный результат
• Механизм
• причина
• Строгость
• Стоимость

Как собирать данные?

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

• Сделайте процедуры простыми

• Избегайте ненужной записи

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

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

• Проверьте все данные, собранные в центральном пункте сбора

Сделайте процедуры простыми

Избегайте ненужной записи

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

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

Проверьте все данные, собранные в центральном пункте сбора

Планирование сбора данных включает в себя несколько этапов –

• Решите, какие продукты измерять на основе анализа GQM

• Убедитесь, что продукт находится под контролем конфигурации

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

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

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

Решите, какие продукты измерять на основе анализа GQM

Убедитесь, что продукт находится под контролем конфигурации

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

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

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

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

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

Как хранить и извлекать данные

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

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

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

Анализ данных измерений программного обеспечения

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

• Природа данных
• Цель эксперимента
• Особенности дизайна

Природа данных

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

Выборка, население и распределение данных

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

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

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

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

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

Цель эксперимента

Обычно проводятся эксперименты –

• Чтобы подтвердить теорию
• Чтобы исследовать отношения

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

Чтобы подтвердить теорию

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

Необходимо рассмотреть два случая данных: нормальные данные и ненормальные данные .

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

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

Чтобы исследовать отношения

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

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

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

• Диаграмма разброса представляет связь между двумя переменными.

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

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

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

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

Диаграмма разброса представляет связь между двумя переменными.

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

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

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

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

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

Особенности дизайна

План исследования должен учитываться при выборе методов анализа. В то же время, сложность анализа может влиять на выбранный дизайн. Несколько групп используют F-статистику, а не T-критерий Стьюдента с двумя группами.

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

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

Внутренние атрибуты продукта

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

Измерение внутренних атрибутов продукта

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

Измерение размера

Размер программного обеспечения можно описать тремя атрибутами:

• Длина – это физический размер продукта.

• Функциональность – описывает функции, предоставляемые продуктом пользователю.

• Сложность – Сложность бывает разных типов, например.

  • Сложность проблемы – Измеряет сложность основной проблемы.

  • Алгоритмическая сложность – измеряет сложность алгоритма, реализованного для решения задачи

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

  • Когнитивная сложность – измеряет усилия, необходимые для понимания программного обеспечения.

Длина – это физический размер продукта.

Функциональность – описывает функции, предоставляемые продуктом пользователю.

Сложность – Сложность бывает разных типов, например.

Сложность проблемы – Измеряет сложность основной проблемы.

Алгоритмическая сложность – измеряет сложность алгоритма, реализованного для решения задачи

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

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

Измерение этих трех атрибутов можно описать следующим образом:

длина

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

Спецификация и дизайн

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

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

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

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

Код

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

Общая длина,

LOC = NCLOC + CLOC

т.е.

LOC = без комментариев LOC + с комментариями LOC

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

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

Он начал с определения программы P как набора токенов, классифицированных по операторам или операндам. Основные метрики для этих токенов были,

• μ ₁ = количество уникальных операторов

• μ ₂ = количество уникальных операндов

• N ₁ = Всего вхождений операторов

• N ₂ = количество уникальных операторов

μ ₁ = количество уникальных операторов

μ ₂ = количество уникальных операндов

N ₁ = Всего вхождений операторов

N ₂ = количество уникальных операторов

Длина P может быть определена как

N=N1+N2

Словарный запас

 mu= mu1+ mu2

Объем программы = количество умственных сравнений, необходимых для написания программы длиной N , равно

V=N timeslog2 mu

Программный уровень программы P громкости V составляет,

L= fracV astV

Где V ast – потенциальный объем, т. Е. Объем реализации P минимального размера

Инверсией уровня является сложность –

D=1 diagupL

Согласно теории Холстеда, мы можем вычислить оценку L как

L′=1 diagupD= frac2 mu1 times frac mu2N2

Точно так же примерная длина программы составляет  mu1 timeslog2 mu1+ mu2 timeslog2 mu2

Усилие, необходимое для генерации P определяется как

E=V diagupL= frac mu1N2Nlog2 mu2 mu2

Где единица измерения E – элементарное умственное различение, необходимое для понимания P

Другие альтернативы для измерения длины:

• С точки зрения количества байтов памяти компьютера, необходимых для текста программы

• По количеству символов в тексте программы

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

По количеству символов в тексте программы

Объектно-ориентированная разработка предлагает новые способы измерения длины. Pfleeger et al. Установлено, что подсчет объектов и методов приводит к более точным оценкам производительности, чем те, которые используют строки кода.

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

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

Метод функциональной точки Альбрехта

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

Мера Function Point, изначально разработанная Альбрехтом, получила все большую популярность благодаря созданию Международной группы пользователей Function Point (IFPUG) в 1986 году. В 2002 году функциональные точки IFPUG стали международным стандартом ISO – ISO / IEC 20926.

Что такое функциональная точка?

FP (Function Point) – наиболее распространенная метрика функционального типа, подходящая для количественной оценки программного приложения. Он основан на пяти идентифицируемых пользователем логических «функциях», которые разделены на два типа функций данных и три типа транзакционных функций. Для данного программного приложения каждый из этих элементов определяется количественно и взвешивается, считая его характерные элементы, такие как ссылки на файлы или логические поля.

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

Применение метода функциональных точек Альбрехта

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

Определите количество компонентов (EI, EO, EQ, ILF и ELF)

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

• EO – номер внешнего выхода. Это элементарные процессы, в которых производные данные проходят через границу изнутри наружу. В примере системы базы данных библиотеки отобразите список книг, извлеченных для покровителя.

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

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

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

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

EO – номер внешнего выхода. Это элементарные процессы, в которых производные данные проходят через границу изнутри наружу. В примере системы базы данных библиотеки отобразите список книг, извлеченных для покровителя.

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

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

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

Вычислить нескорректированный счетчик функциональных точек (UFC)

• Оцените каждый компонент как низкий, средний или высокий .

• Для транзакций (EI, EO и EQ) рейтинг основан на FTR и DET .

  • FTR – количество файлов, обновленных или на которые есть ссылки.

  • DET – количество распознаваемых пользователем полей.

  • На основании следующей таблицы EI, который ссылается на 2 файла и 10 элементов данных, будет ранжироваться как среднее .

Оцените каждый компонент как низкий, средний или высокий .

Для транзакций (EI, EO и EQ) рейтинг основан на FTR и DET .

FTR – количество файлов, обновленных или на которые есть ссылки.

DET – количество распознаваемых пользователем полей.

На основании следующей таблицы EI, который ссылается на 2 файла и 10 элементов данных, будет ранжироваться как среднее .

финансовые права на передачу	дец
1-5	6-15	> 15
0-1	Низкий	Низкий	Средний
2-3	Низкий	Средний	Высоко
> 3	Средний	Высоко	Высоко

• Для файлов (ILF и ELF) рейтинг основан на RET и DET .

  • RET – количество распознаваемых пользователем элементов данных в ILF или ELF .

  • DET – количество распознаваемых пользователем полей.

  • На основании следующей таблицы ILF, который содержит 10 элементов данных и 5 полей, будет иметь высокий рейтинг.

Для файлов (ILF и ELF) рейтинг основан на RET и DET .

RET – количество распознаваемых пользователем элементов данных в ILF или ELF .

DET – количество распознаваемых пользователем полей.

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

ТВЭ	дец
1-5	6-15	> 15
1	Низкий	Низкий	Средний
2-5	Низкий	Средний	Высоко
> 5	Средний	Высоко	Высоко

• Преобразуйте рейтинги в UFC .

Преобразуйте рейтинги в UFC .

Рейтинг	Ценности
Е.О.	EQ	EI	ILF	ELF
Низкий	4	3	3	7	5
Средний	5	4	4	10	7
Высоко	6	5	6	15	10

Вычислить конечный счетчик функциональных точек (FPC)

• Вычислить поправочный коэффициент (VAF) на основе 14 общих характеристик системы (GSC) .

Вычислить поправочный коэффициент (VAF) на основе 14 общих характеристик системы (GSC) .

Общая характеристика системы	Краткое описание
GSC 1	Передача данных	Сколько средств связи существует для помощи в передаче или обмене информацией с приложением или системой?
GSC 2	Распределенная обработка данных	Как обрабатываются распределенные данные и функции обработки?
GSC 3	Спектакль	Требуется ли пользователю время отклика или пропускная способность?
GSC 4	Сильно используемая конфигурация	Насколько интенсивно используется текущая аппаратная платформа, на которой будет выполняться приложение?
GSC 5	Коэффициент транзакций	Как часто транзакции выполняются ежедневно, еженедельно, ежемесячно и т. Д.?
GSC 6	Ввод данных онлайн	Какой процент информации вводится онлайн?
GSC 7	Эффективность конечного пользователя	Было ли приложение разработано для эффективности конечного пользователя?
GSC 8	Онлайн обновление	Сколько ILF обновляется онлайн транзакцией?
GSC 9	Комплексная обработка	Имеет ли приложение обширную логическую или математическую обработку?
GSC 10	Повторное использование	Было ли приложение разработано для удовлетворения потребностей одного или нескольких пользователей?
GSC 11	Простота установки	Насколько сложна конвертация и установка?
GSC 12	Операционная простота	Насколько эффективны и / или автоматизированы процедуры запуска, резервного копирования и восстановления?
GSC 13	Несколько сайтов	Было ли приложение специально разработано, разработано и поддерживается для установки на нескольких сайтах для нескольких организаций?
GSC 14	Облегчить изменение	Было ли приложение специально разработано, разработано и поддержано для облегчения изменений?

• Взвесьте каждый GSC по шкале от 0 до 5, основываясь на том, не влияет ли он на сильное влияние.

• Вычислить FPC следующим образом –

  FPC = UFC * (0,65+ (сумма ( GSC ) * .01))

Взвесьте каждый GSC по шкале от 0 до 5, основываясь на том, не влияет ли он на сильное влияние.

Вычислить FPC следующим образом –

FPC = UFC * (0,65+ (сумма ( GSC ) * .01))

сложность

Сложность – это отдельная составляющая размера. Это двух типов –

• Сложность проблемы – это количество ресурсов, необходимое для оптимального решения проблемы.

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

  • Сложность времени – ресурс компьютерного времени.

  • Пространство сложности – ресурс памяти компьютера.

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

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

Сложность времени – ресурс компьютерного времени.

Пространство сложности – ресурс памяти компьютера.

Измерение сложности

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

Например: если алгоритм для решения всех случаев конкретной задачи требует вычислений f (n) , то f (n) является асимптотически оптимальным, если для любого другого алгоритма со сложностью g, который решает задачу, f является O (g) . Тогда сложность данной задачи велика – O асимптотически оптимального алгоритма решения задачи.

Измерение структуры

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

Типы структурных мероприятий

Структура программного обеспечения состоит из трех частей. Они –

• Структура потока управления – это последовательность выполнения инструкций в программе.

• Структура потока данных – это поведение данных при взаимодействии с программой.

• Структура данных – это организация элементов данных в форме списков, очереди, стеков или других четко определенных структур вместе с алгоритмом их создания, изменения или удаления.

Структура потока управления – это последовательность выполнения инструкций в программе.

Структура потока данных – это поведение данных при взаимодействии с программой.

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

Измерение структуры управления потоком

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

Если «m» является структурной мерой, определенной в терминах модели потокового графа, и если программа A является структурно более сложной, чем программа B , то мера m (A) должна быть больше, чем m (B) .

Измерение структуры потока данных

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

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

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

• Локальный косвенный поток – если вызванный модуль возвращает информацию, которая впоследствии передается во второй вызываемый модуль.

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

Локальный прямой поток – если либо модуль вызывает второй модуль и передает ему информацию, либо вызванный модуль возвращает результат вызывающей стороне.

Локальный косвенный поток – если вызванный модуль возвращает информацию, которая впоследствии передается во второй вызываемый модуль.

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

Сложность информационного потока может быть выражена по Генри и Кафуре как,

Сложность потока информации (M) = длина (M) × разветвление (M) × (разветвление (M)) ²

Куда,

• Fan-in (M) – количество локальных потоков, оканчивающихся на M + количество структур данных, из которых информация извлекается M.

• Fan-out (M) – количество локальных потоков, исходящих из M + количество структур данных, которые обновляются M.

Fan-in (M) – количество локальных потоков, оканчивающихся на M + количество структур данных, из которых информация извлекается M.

Fan-out (M) – количество локальных потоков, исходящих из M + количество структур данных, которые обновляются M.

Структура данных измерений

Структура данных может быть как локальной, так и глобальной .

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

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

Стандарты и Сертификаты

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

Следующие институты и организации являются основными разработчиками стандартов SQA и разработки программного обеспечения –

• IEEE (Институт инженеров по электротехнике и электронике) Компьютерное общество
• ISO (Международная организация по стандартизации)
• Министерство обороны США (Министерство обороны США)
• ANSI (Американский национальный институт стандартов)
• IEC (Международная электротехническая комиссия)
• EIA (Ассоциация электронной промышленности)

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

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

Они также предоставляют инструменты для самооценки системы SQA организации и ее функционирования. Примерами этого подхода являются Модель зрелости емкости (CMM), разработанная Институтом разработки программного обеспечения (SEI), Университетом Карнеги-Меллона и стандартом ISO / IEC Std 15504.

Стандарты SQA

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

• Стандарты управления обеспечением качества программного обеспечения, включая методологии сертификации и оценки (стандарты управления качеством)

• Стандарты процесса разработки программного обеспечения (стандарты процесса проекта)

Стандарты управления обеспечением качества программного обеспечения, включая методологии сертификации и оценки (стандарты управления качеством)

Стандарты процесса разработки программного обеспечения (стандарты процесса проекта)

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

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

Пример – ИСО 9000-3 и модель зрелости возможностей (CMM)

Стандарты процесса проекта

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

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

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

Характеристики этих двух классов стандартов приведены в следующей таблице.

Характеристики	Стандарты управления качеством	Стандарты процесса проекта
Целевая единица	Управление разработкой программного обеспечения, обслуживанием и конкретными подразделениями SQA	Команда проекта разработки и сопровождения программного обеспечения
Основное внимание	Организация систем SQA, инфраструктуры и требований	Методология выполнения проектов разработки и сопровождения программного обеспечения.
Цель стандарта	«Что» достичь	«Как» выполнить
Цель стандарта	Обеспечение качества программного обеспечения поставщика и оценка возможностей его программного процесса	Обеспечение качества программного обеспечения поставщика и оценка возможностей его программного обеспечения. Обеспечение качества конкретного программного проекта.
Примеры	ISO 9000-3 SEI CMM	ISO / IEC 12207 IEEEStd 1012-1998

Сертификация ISO 9001

ISO (Международная организация по стандартизации) – всемирная федерация национальных органов стандартизации. Технические комитеты ISO готовят международные стандарты. ИСО тесно сотрудничает с Международной электротехнической комиссией (МЭК) по всем вопросам электротехнической стандартизации.

Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО / МЭК, часть 2. Проект международных стандартов, принятый техническими комитетами, направляется в органы-члены для голосования. ISO 9001 был подготовлен Техническим комитетом ISO / TC 176, Управление качеством и обеспечение качества, Подкомитетом SC 2, Системы качества.

Процессный подход

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

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

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

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

ISO 9001 – Применение к программному обеспечению: инициатива TickIT

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

Кроме того, TickIT специализируется на информационных технологиях (ИТ). Он охватывает весь спектр коммерческих услуг по разработке и сопровождению программного обеспечения. TickIT, в настоящее время управляемый и поддерживаемый Департаментом DISC BSI (Британский институт стандартов), аккредитован для сертификации ИТ-организаций в Великобритании и Швеции.

Его деятельность включает в себя –

• Публикация Руководства TickIT, которое поддерживает усилия индустрии программного обеспечения по распространению сертификации ISO 9001. Текущее руководство (издание 5.0, TickIT, 2001), которое включает ссылки на ИСО / МЭК 12207 и ИСО / МЭК 15504, распространяется среди всех клиентов TickIT.

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

• Провести сертификационный аудит ISO 9000.

Публикация Руководства TickIT, которое поддерживает усилия индустрии программного обеспечения по распространению сертификации ISO 9001. Текущее руководство (издание 5.0, TickIT, 2001), которое включает ссылки на ИСО / МЭК 12207 и ИСО / МЭК 15504, распространяется среди всех клиентов TickIT.

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

Провести сертификационный аудит ISO 9000.

Аудиторы TickIT, проводящие аудиторские оценки и сертификационные аудиты, зарегистрированы Международным регистром сертифицированных аудиторов (IRCA). Зарегистрированные аудиторы IRCA обязаны, помимо прочего, иметь опыт управления и разработки программного обеспечения; они также должны успешно пройти курс одитора.

Зарегистрированные ведущие аудиторы должны иметь подтвержденный опыт в проведении и руководстве аудитами TickIT.

Оценка процесса разработки программного обеспечения

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

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

• Самооценка (первичная оценка) выполняется внутри организации персоналом организации.

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

• Сторонняя оценка выполняется внешней стороной или (например, поставщиком, который оценивается третьей стороной для проверки ее способности заключать контракты с клиентом).

Самооценка (первичная оценка) выполняется внутри организации персоналом организации.

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

Сторонняя оценка выполняется внешней стороной или (например, поставщиком, который оценивается третьей стороной для проверки ее способности заключать контракты с клиентом).

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

Оценка зрелости программного процесса

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

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

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

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

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

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

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

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

Цикл Оценки Программного Процесса

Согласно Paulk и коллегам (1995), подход к оценке на основе CMM использует шестиступенчатый цикл. Они –

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

• Представители оцениваемого сайта заполняют стандартную анкету зрелости процесса.

• Команда оценки выполняет анализ ответов на вопросник и определяет области, которые требуют дальнейшего изучения, в соответствии с ключевыми областями процесса ШМ.

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

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

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

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

Представители оцениваемого сайта заполняют стандартную анкету зрелости процесса.

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

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

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

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

Например, группа по оценке должна возглавляться уполномоченным ведущим оценщиком SEI. Команда должна состоять из четырех-десяти членов команды. По крайней мере, один член команды должен быть из оцениваемой организации, и все члены команды должны пройти курс SEI «Введение в CMM» (или его эквивалент) и курс обучения команды SEI CBA IPI. Члены команды также должны соответствовать некоторым правилам отбора.

Что касается сбора данных, ИПБ ЦБА использует четыре метода:

• Стандартный вопросник зрелости
• Индивидуальные и групповые интервью
• Обзоры документов
• Отзывы о рассмотрении проекта выводов с участниками оценки

SCAMPI

Стандартный метод оценки CMMI для улучшения процессов (SCAMPI) был разработан для удовлетворения требований модели CMMI (Software Engineering Institute, 2000). Он также основан на IPA ЦБА. И CBA IPI, и SCAMPI состоят из трех этапов:

• План и подготовка
• Провести оценку на месте
• Отчет о результатах

Действия для плана и подготовительного этапа включают в себя –

• Определите область оценки
• Разработать план оценки
• Подготовить и обучить оценочную команду
• Сделайте краткую оценку участникам
• Администрирование оценочной анкеты CMMI
• Изучите ответы на анкету
• Провести первоначальный обзор документа

Мероприятия для этапа оценки на месте включают в себя –

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

Мероприятия на этапе представления отчетности включают в себя:

• Представьте окончательные результаты
• Провести исполнительную сессию
• Завершите оценку

Гарантия качества

Определение IEEE для обеспечения качества программного обеспечения следующее:

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

Цели деятельности SQA

Цели деятельности SQA заключаются в следующем –

В разработке программного обеспечения (процессно-ориентированный)

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

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

• Инициирование и управление деятельностью по улучшению и повышению эффективности разработки программного обеспечения и деятельности SQA.

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

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

Инициирование и управление деятельностью по улучшению и повышению эффективности разработки программного обеспечения и деятельности SQA.

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

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

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

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

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

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

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

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

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

Менеджеры

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

• Руководители отдела разработки и сопровождения программного обеспечения

• Менеджеры отдела тестирования программного обеспечения

• Менеджеры проектов и руководители команд разработки и сопровождения проектов

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

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

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

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

Менеджеры проектов и руководители команд разработки и сопровождения проектов

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

Тестеры

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

Специалисты SQA и заинтересованные практики –

• SQA попечители
• Члены комитета SQA
• Участники форума SQA
• Члены команды подразделения SQA

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

Роль менеджмента в QA

По сути, в организациях по разработке программного обеспечения существует трехуровневая структура управления –

• Высшее руководство
• Управление отделом
• Управление проектом

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

Ниже приведены обязанности высшего руководства по обеспечению качества программного обеспечения.

• Обеспечение качества программных продуктов компании и услуг по сопровождению программного обеспечения

• Сообщите о важности качества продукции и услуг в дополнение к удовлетворенности клиентов сотрудникам на всех уровнях.

• Обеспечить удовлетворительное функционирование и полное соответствие требованиям заказчика

• Убедитесь, что цели качества установлены для системы SQA организации и что ее цели достигнуты

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

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

• Обеспечить доступность ресурсов, необходимых для систем SQA

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

Сообщите о важности качества продукции и услуг в дополнение к удовлетворенности клиентов сотрудникам на всех уровнях.

Обеспечить удовлетворительное функционирование и полное соответствие требованиям заказчика

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

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

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

Обеспечить доступность ресурсов, необходимых для систем SQA

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

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

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

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

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

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

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

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

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

• Соответствие цели и задачам организации

• Приверженность общим концепциям обеспечения качества программного обеспечения

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

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

• Стремление к постоянному улучшению качества и производительности организации

Соответствие цели и задачам организации

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

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

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

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

Ответственный за качество программного обеспечения

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

• Ответственность за подготовку ежегодной программы мероприятий и бюджета SQA

• Ответственность за подготовку планов развития системы SQA

• Общий контроль за выполнением ежегодной программы регулярных мероприятий SQA и запланированных проектов развития SQA

• Презентация и пропаганда вопросов SQA для исполнительного руководства

Ответственность за подготовку ежегодной программы мероприятий и бюджета SQA

Ответственность за подготовку планов развития системы SQA

Общий контроль за выполнением ежегодной программы регулярных мероприятий SQA и запланированных проектов развития SQA

Презентация и пропаганда вопросов SQA для исполнительного руководства

Ответственность за подготовку ежегодной программы мероприятий SQA

Это требует исполнительной власти –

• Установить цели системы SQA на предстоящий год

• Рассмотреть предложения, подготовленные отделом SQA для ежегодной программы мероприятий, и проверить потенциал предложения для достижения целей, установленных для системы SQA.

• Определите, соответствует ли программа мероприятий характеристикам и объему услуг субподрядчика и закупок программного обеспечения, запланированных на предстоящий год

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

• Утвердить окончательный вариант годовой программы мероприятий и бюджета SQA.

Установить цели системы SQA на предстоящий год

Рассмотреть предложения, подготовленные отделом SQA для ежегодной программы мероприятий, и проверить потенциал предложения для достижения целей, установленных для системы SQA.

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

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

Утвердить окончательный вариант годовой программы мероприятий и бюджета SQA.

Ответственность за подготовку планов развития системы SQA

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

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

• Рассмотреть предложения по адаптации SQA, таким как подготовка новых процедур, соответствующих новым инструментам и стандартам SQA.

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

• Разработка метрик качества программного обеспечения, подходящих для оценки новых инструментов и стандартов, а также успеха учебных программ

• Утверждение окончательной версии запланированных проектов развития SQA, включая их графики и бюджеты.

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

Рассмотреть предложения по адаптации SQA, таким как подготовка новых процедур, соответствующих новым инструментам и стандартам SQA.

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

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

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

Общий контроль выполнения годовой программы SQA

Ответственный исполнитель несет ответственность за:

• Общий надзор за ежегодной программой мероприятий

• Обзор хода реализации адаптационных проектов SQA

• Общий надзор за действиями, предпринимаемыми для реализации качественных достижений, продиктованных целями команд (на основе периодических отчетов)

• Проверка соответствия процедурам и стандартам SQA на основе внутренних аудитов качества

• Общее отслеживание соблюдения графиков и бюджетов проектов разработки программного обеспечения

• Общее отслеживание предоставления качественных сервисных услуг внешним и внутренним клиентам

Общий надзор за ежегодной программой мероприятий

Обзор хода реализации адаптационных проектов SQA

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

Проверка соответствия процедурам и стандартам SQA на основе внутренних аудитов качества

Общее отслеживание соблюдения графиков и бюджетов проектов разработки программного обеспечения

Общее отслеживание предоставления качественных сервисных услуг внешним и внутренним клиентам

Презентация и пропаганда вопросов SQA для исполнительного руководства

Для повышения качества и устранения трудностей системы SQA требуется:

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

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

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

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

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

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

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

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

Ответственность руководства департамента за SQA

Обязанности среднего звена по обеспечению качества включают в себя:

• Управление системой менеджмента качества программного обеспечения (задачи, связанные с системой качества)

• Управление задачами, связанными с проектами и услугами, выполняемыми группами или командами под руководством конкретного менеджера (задачи, связанные с проектами)

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

Управление задачами, связанными с проектами и услугами, выполняемыми группами или командами под руководством конкретного менеджера (задачи, связанные с проектами)

Обязанности, связанные с системой качества

К ним относятся действия SQA, которые должны выполняться на уровне отдела –

• Подготовка годовой программы и бюджета SQA для отдела на основе рекомендованной программы, подготовленной подразделением SQA

• Подготовка планов развития систем SQA департамента на основе рекомендованного плана, подготовленного подразделением SQA

• Контроль за выполнением ежегодной программы деятельности SQA отдела и проектов развития

• Представление вопросов SQA отдела высшему руководству

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

Подготовка планов развития систем SQA департамента на основе рекомендованного плана, подготовленного подразделением SQA

Контроль за выполнением ежегодной программы деятельности SQA отдела и проектов развития

Представление вопросов SQA отдела высшему руководству

Обязанности, связанные с проектом

Они различаются в зависимости от процедур организации и распределения полномочий; они обычно включают в себя –

• Контроль за соблюдением процедур обеспечения качества в подразделениях департамента, включая органы CAB, SCM и SCCA

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

• Проверка эффективности выполнения запланированных мероприятий; утверждение проектной документации и завершение фазы проекта

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

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

• Консультирование и поддержка руководителей проектов в решении проблем с графиком, бюджетом и отношениями с клиентами

• Контроль качества предоставления сервисных услуг

• Подробное отслеживание рисков проекта и их решения

• Отслеживание соответствия проекта требованиям заказчика и удовлетворенности потребителя

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

Контроль за соблюдением процедур обеспечения качества в подразделениях департамента, включая органы CAB, SCM и SCCA

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

Проверка эффективности выполнения запланированных мероприятий; утверждение проектной документации и завершение фазы проекта

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

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

Консультирование и поддержка руководителей проектов в решении проблем с графиком, бюджетом и отношениями с клиентами

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

Подробное отслеживание рисков проекта и их решения

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

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

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

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

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

• Профессиональные практические задания

  • Подготовка проекта и планов качества и их обновления

  • Участие в совместном комитете заказчик-поставщик

  • Тщательное наблюдение за персоналом проектной команды, включая участие в подборе, обучении и обучении

• Задачи управления

  Руководители проектов решают следующие вопросы, такие как –

  • Выполнение проверок и последующие исправления

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

  • Выполнение приемочных испытаний

  • Установка программного обеспечения на удаленных клиентских сайтах и ​​выполнение программного обеспечения клиентом.

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

  • Графики и ресурсы, выделенные для деятельности по проекту

  • Запросы клиентов и удовлетворение

  • Развивающиеся риски развития проекта, применение решений и контроль результатов

Профессиональные практические задания

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

Участие в совместном комитете заказчик-поставщик

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

Задачи управления

Руководители проектов решают следующие вопросы, такие как –

Выполнение проверок и последующие исправления

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

Выполнение приемочных испытаний

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

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

Графики и ресурсы, выделенные для деятельности по проекту

Запросы клиентов и удовлетворение

Развивающиеся риски развития проекта, применение решений и контроль результатов

SQA Unit

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

Задачи, выполняемые начальником отдела SQA

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

• Планирование задач
• Управление подразделением
• SQA профессиональная деятельность

Планирование задач

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

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

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

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

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

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

Задачи управления

• Управление деятельностью команды SQA

• Мониторинг реализации программы деятельности SQA

• Назначение членов команды, членов комитета SQA и попечителей SQA

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

Управление деятельностью команды SQA

Мониторинг реализации программы деятельности SQA

Назначение членов команды, членов комитета SQA и попечителей SQA

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

SQA Профессиональная деятельность

• Участие в совместных проектных комитетах
• Участие в официальных обзорах дизайна
• Рассмотрение и утверждение отклонений от спецификаций
• Консультация с менеджерами проектов и руководителями команд
• Участие в комитетах и ​​форумах SQA

Проект жизненного цикла SQA

Задачи SQA, относящиеся к подразделу жизненного цикла проекта, можно разделить на две группы:

• «Чистые» управленческие задачи контроля и одобрения (задачи управления жизненным циклом проекта)

• «Практическое занятие» или активное участие в деятельности SQA команды проекта, где требуется профессиональный вклад (задачи участия)

«Чистые» управленческие задачи контроля и одобрения (задачи управления жизненным циклом проекта)

«Практическое занятие» или активное участие в деятельности SQA команды проекта, где требуется профессиональный вклад (задачи участия)

Задачи управления жизненным циклом проекта

• Отслеживание соответствия команды разработчиков и сопровождения процедурам SQA и рабочим инструкциям

• Утверждение или рекомендация программных продуктов согласно соответствующим процедурам

• Контроль за предоставлением услуг по сопровождению программного обеспечения внутренним и внешним клиентам

• Мониторинг удовлетворенности клиентов и поддержание контактов с представителями по обеспечению качества клиентов

Отслеживание соответствия команды разработчиков и сопровождения процедурам SQA и рабочим инструкциям

Утверждение или рекомендация программных продуктов согласно соответствующим процедурам

Контроль за предоставлением услуг по сопровождению программного обеспечения внутренним и внешним клиентам

Мониторинг удовлетворенности клиентов и поддержание контактов с представителями по обеспечению качества клиентов

Задачи участия

Эти задачи включают участие в –

• Контрактные обзоры
• Подготовка и обновление планов развития проекта и качества
• Формальные дизайнерские обзоры
• Официальные обзоры дизайна субподрядчиков
• Тестирование программного обеспечения, включая приемочные тесты
• Приемочные испытания программного обеспечения субподрядчиков
• Установка новых программных продуктов

Операционные задачи инфраструктуры SQA

Системы SQA используют различные компоненты инфраструктуры для бесперебойной работы, а именно:

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

Более конкретно, задачи подразделения SQA относительно этих компонентов включают в себя:

• Публикация обновленных версий процедур, рабочих инструкций, шаблонов, контрольных списков и т. Д. Вместе с их распространением в печатном виде и / или электронными средствами.

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

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

• Мониторинг и поддержка внедрения новых и пересмотренных процедур SQA

• Последующие мероприятия по сертификации персонала

• Предложение вопросов, требующих профилактических и корректирующих действий, включая участие в комитетах CAB

• Последующие действия по управлению конфигурацией, включая участие в комитетах CCA

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

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

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

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

Мониторинг и поддержка внедрения новых и пересмотренных процедур SQA

Последующие мероприятия по сертификации персонала

Предложение вопросов, требующих профилактических и корректирующих действий, включая участие в комитетах CAB

Последующие действия по управлению конфигурацией, включая участие в комитетах CCA

Контроль за соблюдением процедур документирования и рабочих инструкций

Задачи внутреннего аудита и сертификации SQA

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

• Внутренние аудиты

• Аудиты субподрядчиков и поставщиков для оценки их систем SQA

• Внешние аудиты, проводимые органами по сертификации

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

Внутренние аудиты

Аудиты субподрядчиков и поставщиков для оценки их систем SQA

Внешние аудиты, проводимые органами по сертификации

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

Первые два класса проверок инициируются и выполняются подразделением SQA, последние два – внешними органами.

Блок SQA выполняет следующие задачи для внутренних аудитов SQA

• Подготовка годовых программ для внутренних аудитов SQA

• Проведение внутренних аудитов SQA

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

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

Подготовка годовых программ для внутренних аудитов SQA

Проведение внутренних аудитов SQA

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

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

Подразделение SQA выполняет следующие задачи для аудитов субподрядчиков и поставщиков –

• Подготовка годовой программы аудита SQA субподрядчиков и поставщиков

• Проведение SQA аудитов субподрядчиков и поставщиков

• Последующие исправления и улучшения должны выполняться проверенными субподрядчиками и поставщиками

• Сбор данных о работе субподрядчиков и поставщиков из внутренних и внешних источников

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

  • Рекомендации по сертификации субподрядчиков и поставщиков

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

    • Согласование содержания и графика сертификационного аудита

    • Подготовка документов, указанных органами по сертификации

    • Инструктирование проверенных команд и выполнение подготовительных работ, необходимых для сертификационных аудитов

    • Участие в сертификационных аудитах

    • Убедитесь, что необходимые исправления и улучшения выполнены

Подготовка годовой программы аудита SQA субподрядчиков и поставщиков

Проведение SQA аудитов субподрядчиков и поставщиков

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

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

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

Рекомендации по сертификации субподрядчиков и поставщиков

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

Согласование содержания и графика сертификационного аудита

Подготовка документов, указанных органами по сертификации

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

Участие в сертификационных аудитах

Убедитесь, что необходимые исправления и улучшения выполнены

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

• Согласование содержания и графика аудита

• Подготовка документов, указанных аудитором заказчика

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

• Участие в аудитах

• Убедитесь, что необходимые исправления и улучшения выполнены

Согласование содержания и графика аудита

Подготовка документов, указанных аудитором заказчика

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

Участие в аудитах

Убедитесь, что необходимые исправления и улучшения выполнены

Задачи поддержки SQA

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

• Подготовка планов проекта и планов качества проекта

• Штатные обзорные бригады

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

• Выбор мер для устранения задержек в графике и превышения бюджета

• Выбор метрик SQA и компонентов стоимости программного обеспечения

• Использование информационной системы SQA

• Выбор методологий и инструментов разработки, отражающих данные об отказах, накопленные модулем SQA

Подготовка планов проекта и планов качества проекта

Штатные обзорные бригады

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

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

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

Использование информационной системы SQA

Выбор методологий и инструментов разработки, отражающих данные об отказах, накопленные модулем SQA

SQA Стандарты и процедуры Задачи

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

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

• Отвечать за разработку новых процедур и обновлений процедур с участием в соответствующих комитетах и ​​форумах.

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

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

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

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

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

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

SQA Инженерные задачи

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

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

• Тестирование аспектов качества и производительности в отношении новых инструментов разработки и новых версий используемых в настоящее время инструментов разработки

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

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

• Разработка методов измерения качества программного обеспечения и производительности команды

• Оказание технологической поддержки комитетам CAB при анализе сбоев разработки программного обеспечения и разработке предлагаемых решений.

Тестирование аспектов качества и производительности в отношении новых инструментов разработки и новых версий используемых в настоящее время инструментов разработки

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

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

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

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

Задачи SQA Information Systems

Информационные системы SQA предназначены для облегчения и улучшения функционирования систем SQA. Задачи включают в себя –

• Разработка информационных систем SQA для подразделений по разработке и сопровождению программного обеспечения для

  • сбор данных о деятельности

  • обработка, например, периодических отчетов, списков, отчетов об исключениях и запросов

  • обработка, например, периодических отчетов, списков, отчетов об исключениях и запросов

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

• Обновление информационных систем SQA

• Разработка и поддержка сайта организации SQA Internet / Intranet

Разработка информационных систем SQA для подразделений по разработке и сопровождению программного обеспечения для

сбор данных о деятельности

обработка, например, периодических отчетов, списков, отчетов об исключениях и запросов

обработка, например, периодических отчетов, списков, отчетов об исключениях и запросов

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

Обновление информационных систем SQA

Разработка и поддержка сайта организации SQA Internet / Intranet

SQA попечители и их задачи

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

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

Задачи, связанные с юнитами

• Поддержка коллег в решении трудностей при внедрении процедур качества программного обеспечения и рабочих инструкций

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

• Содействовать соблюдению и контролировать выполнение процедур SQA и рабочих инструкций коллегами

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

• Сообщить о серьезных сбоях качества программного обеспечения в блок SQA

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

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

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

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

Сообщить о серьезных сбоях качества программного обеспечения в блок SQA

Задачи, связанные с организацией

• Инициировать изменения и обновления общеорганизационных процедур SQA и рабочих инструкций

• Триггерные улучшения процессов разработки и сопровождения в организации

• Инициировать приложения в CAB относительно решений для периодических сбоев, наблюдаемых в соответствующих единицах

• Определите потребности в обучении SQA по всей организации и предложите соответствующую программу обучения или инструктаж для подразделения SQA

Инициировать изменения и обновления общеорганизационных процедур SQA и рабочих инструкций

Триггерные улучшения процессов разработки и сопровождения в организации

Инициировать приложения в CAB относительно решений для периодических сбоев, наблюдаемых в соответствующих единицах

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

Комитеты SQA и их задачи

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

• Постоянные комитеты обычно имеют дело с SCC (Software Change Control), CA (корректирующие действия), процедурами, инструментами разработки методов и показателями качества.

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

Постоянные комитеты обычно имеют дело с SCC (Software Change Control), CA (корректирующие действия), процедурами, инструментами разработки методов и показателями качества.

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

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

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

Кадр: фильм «Белоснежка и охотник»

Обозреватель Skillbox Media, отраслевой журналист. Работала с TexTerra, SMMplanner, «Нетологией», «ПланФактом», Semantica. Написала больше 60 текстов для рекламных кампаний в «Дзене». Вела нишевой канал на YouTube.

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

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

---

Есть множество классификаций стилей управления. Самая распространённая — деление на авторитарный, демократический и либеральный. Она связана с именами двух психологов: Курта Левина и Дугласа Макгрегора.

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

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

В 1939 году Курт Левин, Рональд Липпит и Ральф Уайт провели эксперимент, результаты которого опубликовали в The Journal of Social Psychology. Они собрали три группы мальчиков 10–11 лет, попросили их делать маски из папье-маше и назначили в группах руководителей с разными стилями управления. В ходе наблюдения выяснили, что:

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

Левин считал демократический стиль самым эффективным. При этом он отмечал, что авторитарный менеджмент добивался от подчинённых большего объёма работ, чем демократический. Попустительский стиль Левин считал неэффективным — при нём снижались качество и объём, сотрудники были неудовлетворены руководством.

Похожую классификацию разработал американский социальный психолог Дуглас Макгрегор. В 1960 году он выпустил книгу The Human Side of Enterprise, в которой разделил стили управления всего на два вида:

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

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

Макгрегор утверждает, что тип контроля зависит от зрелости работников. Незрелые и зависимые работники требуют более строгого контроля и авторитарного стиля. Зрелые и независимые работники не нуждаются в «диктатуре» — им подойдёт демократический стиль управления.

Левин и Макгрегор солидарны: применимы и авторитарный, и демократический стили управления. Всё зависит от того, кто, когда и где их использует.

Авторитарный и демократический стили есть и в классификациях других специалистов. Например, американский писатель и психолог Дэниел Гоулман выделяет шесть стилей руководства — и среди них командующий и демократический.

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

На стиль управления руководителей влияют три вещи: личность, компания и подчинённые.

От личности руководителя зависит то, как он общается с подчинёнными: способен ли прислушиваться к их идеям, может ли жёстко управлять в кризисных ситуациях, заботится ли о сотрудниках и вникает ли в их проблемы. Управляющий директор брендингового агентства «Логомашина» Александр Бодров считает, что именно личность влияет на стиль больше всего.

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

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

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

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

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

Gallup в исследовании 2013 года утверждает, что в США всего 30% сотрудников максимально вовлечены в работу и вдохновлены ей: «Мы предполагаем, что у них прекрасные руководители». В целом по миру аналогичный показатель составил 13%.

Учёные Хунлей Ван и Бичен Гуань провели исследование и выяснили, что авторитарный стиль управления повышает производительность труда в правильной среде. Под правильной средой они понимают традиционную культуру, распространённую в Китае и других азиатских странах.

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

Опрошенные эксперты констатируют: всё зависит от того, подходит ли стиль управления компании и подчинённым. Это показывает и пример, приведённый HR-директором Corex Logistics Станиславом Глушко. В одном из отделов он столкнулся с микроменеджментом: руководитель управлял даже мелкими процессами.

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

Анна Силина из «Гермес Групп» уточняет, что в любой компании можно повысить эффективность работы сотрудников за счёт развития вовлечённости, работы с брендом работодателя, а также за счёт внедрения системы по управлению результатами деятельности сотрудников.

«У нас в „Гермес Групп“ довольно низкая текучесть кадров, 70% руководителей — это люди, которые лояльны компании и работают в ней более семи лет, а компания стабильно растёт. Несмотря на пандемию, в 2021 году мы показали значительный рост выручки», — рассказывает Анна Силина.

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

Преподаватель курса «HR-менеджер с нуля» от Skillbox и руководитель направления Digital Learning в крупной розничной компании Анастасия Свешникова говорит, что в её организации придерживаются так называемого «близкого менеджмента». Это значит, что руководитель хорошо знает своих сотрудников, их личные обстоятельства, сильные стороны и точки роста. Менеджер выбирает стиль управления, который подходит сотруднику, строит с ним доверительные рабочие отношения, последовательно даёт обратную связь.

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

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

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

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

Она рекомендует молодым руководителям изучить ситуационную модель лидерства Херси — Бланшара. Модель основана на выборе стиля управления в зависимости от уровня, мотивации сотрудника, а также сложности задач, которые необходимо решать. Изучение ситуационной модели руководства, по мнению эксперта, поможет руководителям подобрать правильный стиль управления в разных ситуациях.

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

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

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

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

Ещё несколько материалов для руководителей

Эффективный руководитель

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

Узнать про курс

Как зарабатывать больше с помощью нейросетей?
Бесплатный вебинар: 15 экспертов, 7 топ-нейросетей. Научитесь использовать ИИ в своей работе и увеличьте доход.
Узнать больше