- •Содержание
- •1.13. Задания для самопроверки 59
- •1.17. Задания для самопроверки 88
- •1.19. Задания для самопроверки 108
- •1.23. Задания для самопроверки 116
- •1.27. Задания для самопроверки 125
- •1.37. Задания для самопроверки 144
- •1.48. Задания для самопроверки 159
- •Перечень рисунков
- •Перечень таблиц
- •Введение
- •Принятые сокращения
- •1.Жизненный цикл разработки по
- •Программные проект и его атрибуты
- •Ролевые модели в программном проекте
- •Размер и сложность программного проекта
- •Характеристики программного проекта
- •Качество программного продукта
- •Экран проекта и сводка о подходе
- •Критерий smart для формулирования целей
- •Критерии успешности программного проекта
- •Модели жизненного цикла
- •Водопадная модель
- •Модель быстрой разработки приложения
- •Пошаговая модель
- •Спиральная модель Боэма
- •Прототипная модель
- •Выбор модели жизненного цикла
- •Задания для самопроверки
- •2.Типовой каркас для разработки по
- •Программная разработка
- •Планирование проекта
- •Модель cocomo для оценки трудозатрат в проекте
- •Модель slim для оценки трудозатрат в проекте
- •Разработка спецификации требований
- •Отслеживание и контроль
- •Верификация и валидация
- •Обеспечение качества
- •Конфигурационное управление
- •Метрики
- •Повышение квалификации
- •Задания для самопроверки
- •3. Модели зрелости способностей cmm/cmmi
- •Ключевые области процесса в модели cmm
- •Характеристика уровней зрелости в модели cmm
- •Интегрированная модель зрелости способностей cmmi
- •История возникновения
- •Уровни зрелости и области процесса
- •Уровни способностей процесса в модели cmmi
- •Специальные и общие цели и практики процессных областей
- •Характеристики уровней зрелости в модели cmmi
- •Задания для самопроверки
- •4.Управление рисками в программном проекте
- •Модели esi и pmi управления рисками
- •Выявление рисков
- •Анализ рисков
- •Расстановка приоритетов для рисков
- •Планирование рисков
- •Исполнение ответных стратегий
- •Оценивание результатов исполнение ответных стратегий
- •Документирование действий по рискам
- •Заключительное оценивание рисков
- •Задания для самопроверки
- •5.Стандарты качества iso в применении к по
- •Структура и принципы семейства стандартов iso 9000
- •Модели iso 9000 на базе процессов
- •Самооценивание по ключевым элементам iso 9000
- •Задания для самопроверки
- •6.Формальные методы в разработке по
- •Инструменты формализации и верификации
- •Взаимодействие функциональностей
- •Интегрированная технология анализа и верификации
- •Задания для самопроверки
- •7.Некоторые общие технологические приемы
- •Инспекции по Фейгану
- •Диаграммы Исикавы («рыбий скелет»)
- •Инструменты
- •Swot-анализ
- •Сбалансированный экран результативности
- •Технологическая дорожная карта
- •Метод Дельфи
- •Деревья решений
- •Сравнительное ранжирование
- •Методология подвижного программирования
- •Принципы подвижного программирования
- •Рабочий цикл и роли участников
- •Рабочие документы и обстановка
- •Задания для самопроверки
- •8.Сертификация программного обеспечения в авиации
- •История создания серии документов do-178 и ed-12
- •Уровни программного обеспечения
- •Процессы жизненного цикла по авиационных систем
- •Цели процессных деятельностей
- •Рабочие документы и категории их контроля
- •Процесс планирования по
- •Процессы разработки по
- •Определение требований
- •Проектирование
- •Кодирование
- •Верификация
- •Конфигурационное управление
- •Обеспечение качества
- •Контакт с органом сертификации
- •Выводы и рекомендации
- •Задания для самопроверки
- •9.Задания для самостоятельной работы
- •Темы, связанные с единым каркасом для разработки по
- •Перечень тем
- •Краткое описание каждой темы
- •Тема 2. Программная архитектура базового инструмента для распределенного управления программными проектами
- •Тема 3. Профили типовых рабочих компонентов для разработки приложений
- •Тема 1. Прототип метрической базы данных для управления разработкой приложений
- •Тема 5. Репозиторий повторно используемых компонентов
- •Тема 6. Сквозной пример для единого каркаса разработки приложений
- •Темы, связанные применением формальных методов перечень тем
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи краткое описание каждой темы
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи
- •10.Литература
- •11.Приложения
- •Шаблон для одностраничного экрана проекта
- •Примерная структура положения о работе и тз
- •Примерная форма еженедельного отчета
- •Примерная форма презентации на ежемесячном операционном обзоре
- •12.Указатель
Качество программного продукта
Понятие качества программного продукта (software product quality) тесно связано с понятиями дефекта (defect) и ошибки (error, bug).
Дефект программного продукта (defect) – это любое наблюдаемое несоответствие его фактического поведения в допустимых условиях эксплуатации, ожидаемому поведению, как оно определено в спецификации требований.
Ошибка (error) – это причина наблюдаемого дефекта, как правило, присутствующая в коде, но коренящаяся либо в коде, либо в проекте, либо в спецификации требований, либо в аппаратуре.
В англоязычной литературе под ошибкой часто понимается «любая проблема, обнаруженная на той же фазе ЖЦ, где она возникла», а под дефектом – «проблема, обнаруженная на какой-либо из последующих фаз ЖЦ после ее возникновения». Термин fault, используемый наряду с error и defect, означает одновременно и ошибку, и дефект в указанном выше смысле; т.е., любую проблему в программном продукте, независимо от фазы ЖЦ, на которой она была обнаружена.
Таким образом, дефект лишь обнаруживает наличие ошибки в реализации продукта; причем бывает, что один дефект является следствием нескольких различных ошибок и, наоборот, одна и та же ошибка является причиной нескольких разных дефектов. Чем дальше по линии ЖЦ разработки отстоит место обнаружения дефекта в программном продукте от места совершения ошибки, его вызвавшей, тем более высока для исполнителя стоимость выявления места этой ошибки, ее исправления и проверки того, что исправление действительно устранило обнаруженный дефект и не привнесло в продукт новых дефектов. Эти затраты образуют так называемую стоимость плохого программирования (Cost Of Poor Quality – COPQ), снижение которой является важным резервом исполнителя в повышении эффективности своей работы. Эти затраты никак не оплачиваются заказчиком, а лишь повышают себестоимость разработки, снижая тем самым остающуюся у разработчиков прибыль от разработки.
С выявлением дефектов связано понятие «дублирования», когда разные в своем наблюдаемом проявлении дефекты являются по существу одним и тем же дефектом; т.е., сводятся к общей проблеме и, соответственно, к общей ошибке или группе ошибок в коде как своей причине. Устранение этой причины устраняет все эти дефекты.
На основании обследования огромного числа (свыше 3000) реальных программных проектов еще в начале 1980-х годов Боэм (Barry Boehm) установил экспоненциальный рост этих затрат (кривая Боэма – Рис. 2), который с тех пор только постоянно подтверждался дальнейшими исследованиями. Практический вывод из этого наблюдения – стараться не позволять совершаемым в процессе разработки ошибкам «перерастать» в дефекты, а находить их и устранять как можно раньше, сразу же по мере их возникновения, используя различные методы и практики предотвращения дефектов (defect prevention).
Рис. 2. Кривая Боэма – рост затрат на поиск и устранение причин дефектов
Качество программного продукта – это оценка числа оставшихся в нем дефектов, которые могут проявиться при его эксплуатации. Эти оставшиеся дефекты могут быть как известные разработчикам (с поправкой на дублирование), но по разным причинам еще не исправленные, так и еще не выявленные. Для оценки числа оставшихся в коде дефектов, принимаются следующие предположения:
а) каждая ошибка является причиной ровно одного дефекта, а каждый дефект является следствием только одной ошибки; т.е. суммарное число дефектов в продукте (уже известных и еще не выявленных) равно числу ошибок в его коде (это не всегда так, но позволяет упростить ход рассуждений);
б) плотность ошибок (среднее число совершаемых разработчиком ошибок на 1000 строк кода) в создаваемом документе (например, в тексте программы) постоянна и не зависит от его размера (для программ это число «содержательных» строк кода без комментариев и пустых строк);
в) ошибки не зависят друг от друга.
Тогда, если обозначить плотность ошибок через R, а размер кода – через S, то оценка числа ошибок M в этом коде очевидна: M=R×S. Именно столько ошибок (причин дефектов) и следует искать (и устранять!) в данном коде, чтобы рассчитывать на бездефектный (defect-free) продукт.
В процессе разработки продукта ошибки в коде постепенно обнаруживаются и, как правило, устраняются. Если фиксировать (заносить в БД проекта) все наблюдаемые дефекты и находимые по ним ошибки, устраняя дублирование и «ложные тревоги» (обозначив их общее число через N), то текущее качество программного продукта Q определяется как (M-N)/S в предположении, что M≥N. Если это значение устраивает заказчика, то процесс разработки можно заканчивать, в противном случае надо продолжать искать дефекты, выявляя и устраняя их причины – ошибки. Если же в какой-то момент оказалось, что M<N, то это говорит о неточности в определении M, которая, скорее всего, проистекает из-за заниженной оценки для плотности совершения ошибок R. В этом случае надо понять причины такой неточности и устранить ее.
Рис. 3. Измерение качества программного продукта
Этот процесс нахождения и устранения ошибок отображается S-кривой на графике, показывающим зависимость числа найденных (и исправленных!) ошибок от времени (Рис. 3). На графике хорошо видны два характерных «скачка»; обычно первый связан с синтаксическими ошибками, выявляемыми транслятором, а второй – с логическими ошибками, обнаруживаемыми при прогоне тестов. При дальнейшем тестировании новые ошибки обнаруживаются все реже и реже, так что S-кривая становится практически пологой, что говорит о «насыщении» процесса поиска ошибок данными средствами. Если текущее качество продукта не устраивает заказчика, то надо создавать дополнительные тесты или применять какие-либо другие методы верификации и валидации программного обеспечения.
На практике качество поставляемого программного продукта принято оценивать по плотности поставленных дефектов, известных и неизвестных, в пересчете на размер программного кода в 1000 KAELOC.
Можно предположить, что дефекты, содержащиеся в программном коде, являются случайными независимыми событиями и вызывающие их ошибки могут встречаться в каждой строке. При таком условии число случайных событий-дефектов может быть более одного миллиона. Тогда можно предположить, что распределение вероятности присутствия ошибок на строках кода подчиняется нормальному закону.
График плотности вероятности такого распределения показан на Рис. 4. Считают, что качество программного продукта имеет уровень i сигма (сигма – это среднеквадратическое отклонение случайных событий – присутствия дефектов на строках кода), если количество строк кода, не содержащих дефектов, попадает в интервал ±i сигма относительно его математического ожидания m (Рис. 4). Оставшиеся за пределами этого интервала строки кода, содержащие дефекты, определяют плотность дефектов в поставляемом продукте.
В действительности распределение вероятности того, что строка кода, содержит ошибки, часто отклоняется от нормального. По этой причине и по некоторым другим аналогиям из промышленного производства сложных промышленных изделий, на практике для оценки качества программного продукта используются несколько увеличенные плотности дефектов, приведенные в Табл. 3.
Рис. 4. Распределение вероятности присутствия дефектов на строках кода
Как видно из приведенных цифр, программный продукт с уровнем качества 6 сигма может содержать в своем программном коде лишь 3,4 дефекта на один миллион строк на языке ассемблера; т.е., только 3,4 строки из 1 миллиона являются дефектными – содержат ошибку. Этот уровень качества является очень высоким, но реально достижимым при наличии очень высокой дисциплины труда и с соблюдением всех директив стандартного процесса.
Табл. 3. Уровни сигма и оценка числа остаточных дефектов
Уровень сигма |
Дефектов на 1 миллион исходов |
Процент дефектов |
Процент успеха |
1 |
691 462 |
69 |
31 |
2 |
308 538 |
31 |
69 |
3 |
66 807 |
6,7 |
93,3 |
4 |
6 210 |
0,62 |
99,38 |
5 |
233 |
0,023 |
99,977 |
6 |
3,4 |
0,00034 |
99,99966 |
Если объем кода программного продукта в KLOC или KAELOC легко измерить или подсчитать, то как быть с плотностью совершения ошибок? На практике она определяется постепенно, путем фиксирования в БД проектов и подсчета всех найденных ошибок. Если таких проектов выполнено достаточно много для статистически значимой выборки, то по ним можно вычислить среднее значение этой величины, с определенной поправкой на ошибки, оставшиеся не найденными (эта поправка определяется экспертным путем). Интересно отметить, что это значение меняется достаточно медленно и является индивидуальным для данного разработчика или группы разработчиков на протяжении длительного периода времени.
Кроме того, из практики замечено, что плотность ошибок при внесении изменений в код (в частности, при исправлении уже найденных ошибок) в 3 раза выше, чем обычная плотность совершения ошибок при написании кода заново. Это означает, что при внесении изменений в код надо быть предельно внимательным и учитывать это отличие при планировании таких деятельностей.