25.1. Обеспечение качества и стандарты
Деятельность по обеспечению качества направлена на достижение определенного уровня качества при разработке программного обеспечения. Она предполагает определение или выбор стандартов, применяемых либо к самому процессу разработки ПО, либо к готовому продукту. Эти стандарты могут быть частью процессов производства ПО. В ходе выполнения таких процессов могут применяться средства поддержки, учитывающие выбранные (или разработанные) стандарты качества.
В процессе обеспечения качества могут применяться два вида стандартов:
1. Стандарты на продукцию. Применимы к уже готовым программным продуктам. Они включают стандарты на сопроводительную документацию, например структуру документа, описывающего системные требования, а также такие стандарты, как, например, стандарт заголовка комментариев в определении класса объекта, стандарты написания программного кода, определяющие способ использования языка программирования.
2. Стандарты на процесс создания ПО. Определяют ход самого процесса создания программного продукта, например разработку спецификации, процессы проектирования и аттестации. Кроме того, они могут описывать документацию, создаваемую в ходе выполнения этих процессов.
Между стандартами на продукцию и стандартами на процесс существует очень сильная взаимосвязь. Стандарты на продукцию применимы к результату процесса разработки ПО, а стандарты на процесс в большинстве случаев подразумевают выполнение определенных действий, направленных на получение товара, соответствующего стандартам на продукцию.
Стандарты в разработке программной продукции важны по целому ряду причин, основные из которых перечислены ниже:
1. Стандарты аккумулируют все лучшее из практической деятельности по созданию ПО. Как правило, практические знания приобретаются путем долгого поиска и ошибок. Привнесение этого опыта в определенный стандарт помогает избежать повторения прошлых ошибок. Стандарты в данном случае собирают знания и опыт, имеющие значение для организации-разработчика.
2. Стандарты предоставляют необходимую основу для реализации процесса обеспечения качества. Имея в наличии стандарты, обобщающие лучшие знания и опыт, для обеспечения качества достаточно контролировать, чтобы они выполнялись в процессе создания ПО.
3. Стандарты незаменимы, когда работа переходит от одного сотрудника к другому. В этом случае деятельность всех специалистов в организации подчиняется единому нормативу. Следовательно, требуется меньше затрат на изучение сотрудником новой работы.
Создание стандартов по разработке ПО – процесс долгий и утомительный. Такие национальные и международные организации, как Министерство обороны США, Американский национальный институт стандартизации (ANSI), Британский институт стандартов (BSI), НАТО, Институт инженеров по электротехнике и электронике (IEEE), специализируются на создании общих стандартов, которые могут применяться к широкому диапазону возможных программных проектов. Такие органы, как НАТО, или другие оборонные организации могут требовать соблюдения их собственных стандартов в контрактах на создание программного обеспечения.
Национальные (американские) и международные стандарты были разработаны для таких сфер программной деятельности, как терминология инженерии ПО, языки программирования типа Ada и C++, система обозначений, например для символов в схемах и чертежах, процедуры для разработки системных требований, деятельность по обеспечению качества, а также для аттестации ПО.
Примечание: в Советском Союзе процесс создания ПО регламентировался стандартами ГОСТ ЕСПД (Единая система программной документации - серия ГОСТ 19.ХХХ). В настоящее время в России принят ряд стандартов создания автоматизированных систем, в состав которых входит программные компоненты: ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания " и др. Однако эти стандарты имеют ряд недостатков, а некоторые их положения просто устарели. Поэтому отечественные разработчики ПО чаще используют современные международные стандарты. В Украине также принято несколько государственных стандартов на разработку ПО, в том числе ряд стандартов по обеспечению качества.
Группы обеспечения качества, которые занимаются составлением стандартов, обычно основывают нормативы организации на общих национальных и международных стандартах. Используя их в качестве отправного пункта, группа обеспечения качества разрабатывает свой "справочник" по стандартам. В нем содержатся стандарты, отражающие специфику деятельности данной организации. В табл. 24.2 приведены примеры стандартов, которые могут входить в состав такого справочника.
Таблица 25.2. Стандарты на продукцию и процесс разработки ПО
Стандарты на продукцию | Стандарты на процесс разработки ПО |
Форма пересмотра архитектуры ПО
| Руководство по проведению пересмотра архитектуры ПО |
Структура документа, содержащего системные требования | Представление документации по нормативам ЕЭС |
Формат заголовков программ и процедур | Процесс выпуска версии ПО |
Стиль программирования языка Java
| Процесс утверждения плана реализации проекта |
Формат плана реализации проекта | Процесс контроля изменений |
Форма запроса на изменения | Процесс регистрации выполнения тестов |
Иногда специалисты по разработке ПО относятся к стандартам как к бюрократическому наследию, неприменимому к разработке ПО. Особенно это проявляется при выполнении такой утомительной и скучной (однако необходимой для соблюдения стандартов) процедуры, как заполнение всевозможных форм и регистрация работ. Конечно, с общей идеей полезности стандартов все согласны, однако при этом разработчики находят любую удобную причину, по которой именно для их проекта эти стандарты не так уж необходимы.
Чтобы не возникало подобных проблем в работе, менеджеры по качеству, отвечающие за разработку стандартов, должны быть достаточно подготовленными и действовать следующим образом.
1. Вовлечь самих программистов в разработку стандартов. Они должны ясно понимать, с какой целью разрабатывается стандарт, и четко следовать установленным правилам и нормативам. Важно, чтобы документ с описанием стандарта включал не только изложение самого норматива качества, но и объяснение необходимости именно этого норматива.
2. Регулярно просматривать и обновлять стандарты, чтобы идти в ногу с быстро развивающимися технологиями. Как только стандарт разработан, его помещают в справочник организации по стандартам, где его холят и лелеют, меняя с большой неохотой. Справочник по стандартам – вещь для организации необходимая, однако он должен развиваться по мере развития новых технологий.
3. Подумать о том, чтобы обеспечить поддержку стандартов программными средствами везде, где только можно. Всяческие "канцелярские" стандарты вызывают огромное количество жалоб, связанных с нудной и утомительной работой по их выполнению. Если же имеются в наличии средства поддержки, выполнение стандартов не требует больших усилий.
Стандарты на процессы разработки ПО также могут вызвать ряд проблем, если ставят перед командой разработчиков практически неосуществимые задачи. Такие стандарты дают руководящие советы по выполнению работы, при этом менеджеры проектов могут интерпретировать их каждый по-своему. Нет смысла указывать определенное направление работы, если оно неприменимо к данному проекту или к самой команде разработчиков. Поэтому менеджер проекта должен иметь право изменять стандарты процесса создания ПО в соответствии со специфическими условиями именно данного проекта. Здесь следует оговориться, что это утверждение не относится к стандартам на качество готовой продукции и на процесс сопровождения программной системы, которые могут быть изменены только после глубокого изучения данного вопроса.
Менеджер проекта и менеджер по управлению качеством могут легко избежать подводных камней, связанных с "неподходящими" стандартами, путем тщательной разработки плана мероприятий по обеспечению качества. Именно они должны решить, какие стандарты из справочника можно использовать без изменений, какие из них подлежат изменению, а какие следует исключить. Иногда возникает необходимость в разработке нового стандарта, что может быть вызвано условиями выполнения определенного проекта. Например, требуется установить стандарт для формальной спецификации, если прежде в проектах он не использовался. Такие стандарты должны разрабатываться в процессе выполнения проекта.
- З курсу
- З курсу
- Содержание
- Часть I. Инженерные основы программного обеспечения 10
- Часть II. Требования к программному обеспечению 33
- Часть III. Моделирование программного обеспечения 52
- Часть IV. Технологии разработки программного обеспечения 124
- Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения 145
- Часть VI. Управление проектом программного обеспечения 192
- Предисловие
- Часть I. Инженерные основы программного обеспечения
- 1. Введение в программную инженерию
- 1.1. Вопросы и ответы об инженерии программного обеспечения
- 1.2. Профессиональные и этические требования к специалистам по программному обеспечению
- 2. Системотехника вычислительных систем
- 2.1. Интеграционные свойства систем
- 2.2. Система и ее окружение
- 2.3. Моделирование систем
- 2.4. Процесс создания систем
- 2.5. Приобретение систем
- 3. Процесс создания программного обеспечения
- 3.1. Модели процесса создания программного обеспечения
- 3.2. Итерационные модели разработки программного обеспечения
- 3.3. Спецификация программного обеспечения
- 3.4. Проектирование и реализация программного обеспечения
- 3.5. Эволюция программных систем
- 3.6. Автоматизированные средства разработки программного обеспечения
- 4. Технологии производства программного обеспечения
- Часть II. Требования к программному обеспечению
- 5. Требования к программному обеспечению
- 5.1. Функциональные и нефункциональные требования
- 5.2. Пользовательские требования
- 5.3. Системные требования
- 5.4. Документирование системных требований
- 6. Разработка требований
- 6.1. Анализ осуществимости
- 6.2. Формирование и анализ требований
- 6.3. Аттестация требований
- 6.4. Управление требованиям
- 7. Матрица требований. Разработка матрицы требований
- Часть III. Моделирование программного обеспечения
- 8. Архитектурное проектирование
- 8.1. Структурирование системы
- 8.2. Модели управления
- 8.3. Модульная декомпозиция
- 8.4. Проблемно-зависимые архитектуры
- 9. Архитектура распределенных систем
- 9.1. Многопроцессорная архитектура
- 9.2. Архитектура клиент/сервер
- 9.3. Архитектура распределенных объектов
- 9.4. Corba
- 10. Объектно-ориентированное проектирование
- 10.1. Объекты и классы объектов
- 10.2. Процесс объектно-ориентированного проектирования
- 10.2.1. Окружение системы и модели ее использования
- 10.2.2. Проектирование архитектуры
- 10.2.3. Определение объектов
- 10.2.4. Модели архитектуры
- 10.2.5. Специфицирование интерфейсов объектов
- 10.3. Модификация системной архитектуры
- 11. Проектирование систем реального времени
- 11.1. Проектирование систем реального времени
- 11.2. Управляющие программы
- 11.3. Системы наблюдения и управления
- 11.4. Системы сбора данных
- 12. Проектирование с повторным использованием компонентов
- 12.1. Покомпонентная разработка
- 12.2. Семейства приложений
- 12.3. Проектные паттерны
- 13. Проектирование интерфейса пользователя
- 13.1. Принципы проектирования интерфейсов пользователя
- 13.2. Взаимодействие с пользователем
- 13.3. Представление информации
- 13.4. Средства поддержки пользователя
- 13.5. Оценивание интерфейса
- Часть IV. Технологии разработки программного обеспечения
- 14. Жизненный цикл программного обеспечения: модели и их особенности
- 14.1. Каскадная модель жизненного цикла
- 14.2. Эволюционная модель жизненного цикла
- 14.2.1. Формальная разработка систем
- 14.2.2. Разработка программного обеспечения на основе ранее созданных компонентов
- 14.3. Итерационные модели жизненного цикла
- 14.3.1 Модель пошаговой разработки
- 14.3.2 Спиральная модель разработки
- 15. Методологические основы технологий разработки программного обеспечения
- 16. Методы структурного анализа и проектирования программного обеспечения
- 17. Методы объектно-ориентированного анализа и проектирования программного обеспечения. Язык моделирования uml
- Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения
- 18. Документирование этапов разработки программного обеспечения
- 19. Планирование проекта
- 19.1 Уточнение содержания и состава работ
- 19.2 Планирование управления содержанием
- 19.3 Планирование организационной структуры
- 19.4 Планирование управления конфигурациями
- 19.5 Планирование управления качеством
- 19.6 Базовое расписание проекта
- 20. Верификация и аттестация программного обеспечения
- 20.1. Планирование верификации и аттестации
- 20.2. Инспектирование программных систем
- 20.3. Автоматический статический анализ программ
- 20.4. Метод "чистая комната"
- 21. Тестирование программного обеспечения
- 21.1. Тестирование дефектов
- 21.1.1. Тестирование методом черного ящика
- 21.1.2. Области эквивалентности
- 21.1.3. Структурное тестирование
- 21.1.4. Тестирование ветвей
- 21.2. Тестирование сборки
- 21.2.1. Нисходящее и восходящее тестирование
- 21.2.2. Тестирование интерфейсов
- 21.2.3. Тестирование с нагрузкой
- 21.3. Тестирование объектно-ориентированных систем
- 21.3.1. Тестирование классов объектов
- 21.3.2. Интеграция объектов
- 21.4. Инструментальные средства тестирования
- Часть VI. Управление проектом программного обеспечения
- 22. Управление проектами
- 22.1. Процессы управления
- 22.2. Планирование проекта
- 22.3. График работ
- 22.4. Управление рисками
- 23. Управление персоналом
- 23.1. Пределы мышления
- 23.1.1. Организация человеческой памяти
- 23.1.2. Решение задач
- 23.1.3. Мотивация
- 23.2. Групповая работа
- 23.2.1. Создание команды
- 23.2.2. Сплоченность команды
- 23.2.3. Общение в группе
- 23.2.4. Организация группы
- 23.3. Подбор и сохранение персонала
- 23.3.1. Рабочая среда
- 23.4. Модель оценки уровня развития персонала
- 24. Оценка стоимости программного продукта
- 24.1. Производительность
- 24.2. Методы оценивания
- 24.3. Алгоритмическое моделирование стоимости
- 24.3.1. Модель сосомо
- 24.3.2. Алгоритмические модели стоимости в планировании проекта
- 24.4. Продолжительность проекта и наем персонала
- 25. Управление качеством
- 25.1. Обеспечение качества и стандарты
- 25.1.1. Стандарты на техническую документацию
- 25.1.2. Качество процесса создания программного обеспечения и качество программного продукта
- 25.2. Планирование качества
- 25.3. Контроль качества
- 25.3.1. Проверки качества
- 25.4. Измерение показателей программного обеспечения
- 25.4.1. Процесс измерения
- 25.4.2. Показатели программного продукта
- 26. Надежность программного обеспечения
- 26.1. Обеспечение надежности программного обеспечения
- 26.1.1 Критические системы
- 26.1.2. Работоспособность и безотказность
- 26.1.3. Безопасность
- 26.1.4. Защищенность
- 26.2. Аттестация безотказности
- 26.3. Гарантии безопасности
- 26.4. Оценивание защищенности программного обеспечения
- 27. Совершенствование производства программного обеспечения
- 27.1. Качество продукта и производства
- 27.2. Анализ и моделирование производства
- 27.2.1. Исключения в процессе создания по
- 27.3. Измерение производственного процесса
- 27.4. Модель оценки уровня развития
- 27.4.1. Оценивание уровня развития
- 27.5. Классификация процессов совершенствования