 |
Учебно-методический комплекс ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ |
 |
|
|
|
|
|
Стандарты на продукцию |
Стандарты на процесс разработки ПО |
|
Форма пересмотра архитектуры ПО |
Руководство по проведению пересмотра архитектуры ПО |
|
Структура системных требований |
Представление документации по нормативам ЕЭС |
|
Формат заголовков программ и процедур |
Процесс выпуска версии ПО |
|
Стиль программирования языка JAVA |
Процесс утверждения плана реализации проекта |
|
Формат плана реализации проекта |
Процесс контроля изменений |
|
Форма запроса на изменение |
Процесс регистрации выполнения тестов |
Советы менеджеру по качеству
Необходимо вовлечь программистов в разработку стандартов. Описание стандартов должно содержать не только изложение норматива качества, но и объяснение необходимости выбора именно его.
Регулярно просматривать и обновлять стандарты, которые затем помещаются в справочник организации.
Подумать, как обеспечить поддержку стандартов программными средствами везде, где только можно.
Стандартные документы имеют четкую последовательную структуру, их легко читать и воспринимать.
Выделяют три основные типа стандартов на документацию:
1. Стандарты на процесс создания документации. Определяют способ создания технической документации
2. Стандарты на документ. Определяют структуру и внешний вид.
3. Стандарты на обмен документами. Гарантируют совместимость всех электронных версий документов.
В плане обеспечения качества отображаются стандарты наиболее подходящие к создаваемому ПО. Предлагается следующая структура плана:
1. Представление продукта. Описание продукта, намечаемый рынок его сбыта, а также ожидаемые свойства.
2. Планы выпуска продукта. Назначение крайних сроков выпуска версий программного продукта, распределение ответственности за его разработку и обслуживание.
4. Описания процессов. Представление процессов разработки и обслуживания программного продукта в ходе выполнения проекта и управления им.
5. Цели качества. Планы и цели обеспечения качества продукта, включая описание наиболее важных его характеристик.
6. Риски и управление рисками. Описание основных видов риска, которые могут оказать влияние на уровень качества продукта, и мероприятия, направленные на снижение рисков.
Процесс контроля качества имеет собственный набор процедур и отчетов, которые могут быть использованы в процессе разработки ПО. Они должны иметь четкую структуру.
Выделяют два взаимодополняющих подхода к процессу контроля качества:
Группа разработчиков анализирует документацию, сопровождающую программный продукт, проверяет соответствие документа стандартам.
Программный продукт и его документация проверяется специальной компьютерной программой на его соответствие стандарту.
В проверку качества включена группа специалистов, которые изучают отдельный этап или процесс разработки в целом. В таблице представлены некоторые типы проверок.
Таблица 24 – Типы проверок
|
Тип проверки |
Основная цель проверки |
|
Инспекция структуры и программного кода системы |
Выявить ошибки в требованиях, в структуре и программном коде. Проверка проводится в соответствии с технологической картой возможных ошибок |
|
Промежуточные проверки |
Предоставить отчет о ходе выполнения проекта. |
|
Проверки качества |
Анализ компонентов продукта и документации для выявления несоответствия между спецификацией и структурой системы. |
Измерение показателей ПО – получение числовых значений определенных показателей программного продукта или процесса его разработки.
Показатели программного обеспечения — это количественные показатели, которые можно измерить и которые характеризуют программную систему, процесс разработки ПО или сопровождающую документацию.
Показатели делятся на два вида: контрольные и прогнозируемые. Контрольные показатели обычно соотносятся с процессом разработки ПО, а прогнозируемые — с готовым программным продуктом.
Процесс измерения показателей ПО, который может быть частью контроля качества, показан на рисунке.
Рис. 69 – Процесс измерений показателей качества
Процесс измерений состоит из пяти основных этапов:
1. Выбор показателей для измерения. Определяются измеряемые показатели.
2. Отбор системных компонентов. Часто совсем необязательно оценивать показатели всех компонентов программной системы.
3. Измерение показателей компонентов. Это процесс измерения значений выбранных показателей для отобранных компонентов.
4. Определение аномальных данных. Значения измеренных показателей нужно сравнить между собой и с предыдущими измерениями, занесенными в базу данных.
5. Анализ аномальных компонентов. Определив компоненты с аномальными показателями, их следует изучить для выявления возможного отрицательного влияния на качество программного продукта в целом
Показатели программного продукта можно разделить на два класса:
1. Динамические показатели, которые измеряются в процессе выполнения программы. Относительно легко измерить время выполнения определенных функций и оценить время, необходимое для запуска системы.
2. Статические показатели, которые отражают статические представления системы, например структуру, программный код или документацию. Статические показатели, как правило, имеют отдаленное отношение к качественным характеристикам ПО.
Какими качествами должна обладать система для удобства её сопровождения?
Как избежать ситуации, когда пользователь недоволен качеством ПО, но оно полностью соответствует спецификации?
Можно ли не следовать всем пунктам справочника стандартов ПО, и кто должен заниматься этим вопросом?
Для каких систем целесообразно применять проверку качества группой специалистов, а когда автоматизированной оценкой качества ПО?
Нужно ли оценивать качество прототипа системы? Если да, то какими принципами нужно руководствоваться проверяющему?
Как связаны статические и динамические показатели системы с оценкой качества ПО?
|
|
