Программные продукты и системы

Как известно [1], во время выполнения программного проекта его исполнители допускают ошибки, часть которых переходит в дефекты. При этом оценка общего количества возможных ошибок в ходе выполнения программного проекта и оценка плотности поставляемых дефектов в программном изделии (ПИ) определяется уровнем качества разрабатываемого ПИ и привязывается к размеру его нового кода [2-4]. Деятельность по выявлению и предупреждению возможности возникновения ошибок и дефектов в программном проекте называется предотвращением дефектов. Выполнение этой деятельности в ходе разработки ПИ способствует достижению желаемого уровня качества как самой разработки, так и поставляемого ПИ [4].

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

Отклонение – любая неправильность в совокупности принятых характеристик объекта, ухудшающая какое-либо его свойство.

Ошибка – отклонение, обнаруженное на той же фазе жизненного цикла разработки ПИ, где оно и возникло.

Дефект – отклонение, допущенное на одной из предшествующих его обнаружению фаз жизненного цикла разработки ПИ.

Предъявленный дефект – любой дефект, обнаруженный в объекте.

Открытый дефект – предъявленный дефект, не устраненный к моменту измерения.

Закрытый дефект – предъявленный дефект, устраненный к моменту измерения.

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

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

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

Для повышения эффективности деятельности по предотвращению дефектов ее выполнение необходимо планировать. Причем эта деятельность должна быть обеспечена всеми необходимыми ресурсами и финансированием на уровне каждого проекта [6]. В каждой группе исполнителей программного проекта должен быть ответственный за деятельность по предотвращению дефектов. Ему, как правило, вменяются основные обязанности по разработке ПИ, а деятельность по предотвращению дефектов планируется на неполный рабочий день [4-5]. Для эффективного исполнения своих новых обязанностей ответственный за предотвращение дефектов должен обладать дополнительными знаниями по методам статистического анализа ошибок и дефектов, способам проведения собраний по причинно-следственному анализу и т.п.

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

Модель жизненного цикла отклонения, которая используется на предприятии АОЗТ "Информационные деловые услуги" (ИДУ), г. С.-Петербург, представлена на рисунке 1.

Как видно из рисунка 1, жизненный цикл отклонения включает в себя четыре фазы: "Обнаружение", "Принятие решения", "Устранение" и "Закрытие отклонения". На каждой фазе жизненного цикла отклонения должны собираться реальные данные с целью обеспечения эффективной деятельности по предотвращению дефектов, должна обеспечиваться их достоверность и накопление данных в течение всего жизненного цикла проекта. В ИДУ для осуществления деятельности по предотвращению дефектов используются метрики, представленные ниже.

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

На фазе "Принятие решения" используются такие метрики, как статус отклонения, фаза возникновения отклонения, причина возникновения отклонения; на фазе "Устранение" – трудоемкость устранения отклонения, ФИО лица, осуществившего устранение отклонения, дата устранения отклонения; на фазе "Закрытие" – дата закрытия отклонения, ФИО лица, осуществившего закрытие отклонения.

Практический опыт по выполнению программных проектов, накопленный в АОЗТ ИДУ, подтвердил, что набор представленных метрик является достаточным для обеспечения возможности эффективного исполнения деятельности по предотвращению дефектов в соответствии с установками, изложенными в модели СММ [5].

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

Именно по такому пути пошли мы, создавая специальный модуль автоматизации деятельности по предотвращению дефектов, который был включен в ранее созданную автоматизированную систему советчик (АСС) для руководителя программного проекта [4]. Структура этого модуля представлена на рисунке 2. Основой модуля является база метрических данных программного проекта. Для записи текущих значений метрик в базу данных используется персонифицированная электронная таблица, показанная на рисунке 3.

При вызове этой таблицы на экран монитора она автоматически привязывается к сетевым системным часам. В центре экранной формы над таблицей высвечивается дата текущего календарного дня, изменение даты разработчику недоступно. Кроме того, эта таблица автоматически привязывается к ФИО исполнителя, работающего на компьютере, на экран монитора которого вызвана настоящая таблица. Подробней о персонифицированной метрической таблице изложено в [4].

Для автоматизированной записи метрик при открытии отклонения используется экранная форма (ведомость обнаруженных отклонений), представленная на рисунке 4, которая вызывается из экранной формы (рис. 3) путем нажатия соответствующей кнопки.

Заполнение ведомости обнаруженных отклонений выполняет разработчик ПИ, которому поручена роль ответственного за предотвращение дефектов в проектной группе. Одному отклонению в таблице ведомости отведена одна строка. В каждой строке таблицы (см. рис. 4) первые пять столбцов наполняются надлежащим содержанием из списка, который формируется из метрической базы данных проекта. Выбор требуемого содержания производится путем нажатия соответствующей клавиши в левом верхнем углу экранной формы (рис. 4). Эти клавиши обозначены как "Ввод данных для 1-5, 8 столбцов". Описание отклонения вводится разработчиком при помощи клавиатуры и, как правило, включает следующую информацию: в чем именно оно заключается и как проявляется, к чему приводит это проявление и т.п. Для описания отклонения зарезервировано 256 символов. В предпоследний столбец строки заносится реальное значение трудоемкости обнаружения данного отклонения, а в последний – код продукта, содержащего отклонение, который также выбирается из списка. Описанным образом заполняются данные по всем отклонениям, подготовленным к записи в базу данных в текущий календарный день.

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

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

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

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

Для отслеживания изменения количества обнаруженных и устраненных отклонений в АОЗТ ИДУ используется диаграмма, показанная на рисунке 6.

Эта диаграмма состоит из графиков отклонений: предъявленных, открытых и закрытых. Все графики строятся с нарастающим итогом. Кроме того, на диаграмме прочерчена прямая линия, параллельная оси абсцисс. Ордината линии равна оценке количества допустимых отклонений в проекте ПИ с опреде-ленным размером и заданным качеством (подробнее см. [6]).

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

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

На рисунке 8 показана другая диаграмма Парето, представляющая распределение дефектов с учетом стоимости их устранения по категориям продуктов.

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

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

В АОЗТ ИДУ для обеспечения качества ПИ и деятельности по предотвращению дефектов используются диаграммы, которые строятся автоматически: "Распределение отклонений по способам выявления за период, по уровням серьезности и фазам возникновения" и диаграмма "Все предъявленные отклонения за период" (см. рис. 5). Обратим внимание на то, что на диаграмме рисунка 5 в каждом столбце установлен автофильтр данных. Руководитель проекта или любой другой сотрудник может использовать эти автофильтры по своему усмотрению для проведения углубленного анализа возникновения отклонений. Например, можно выяснить, кто из сотрудников больше всего обнаруживает ошибок или на какой фазе обнаруживается больше всего дефектов.

Важное место в деятельности по предотвращению дефектов занимает причинно-следственный анализ. Такой анализ должен проводиться на предприятии в каждой проектной группе [5]. В процессе этого анализа строится причинно-следственная диаграмма Ишикавы [7], получившая название рыбий скелет, потому что такая диаграмма, детально проработанная, напоминает именно его. Диаграмма Ишикавы предназначена для наглядного представления связей между проблемой (следствием) и вызвавшими ее причинами (рис. 10).

Причинно-следственные диаграммы в процессе осуществления деятельности по предотвращению дефектов строят для того, чтобы наглядно представить различные обстоятельства или проблемы, влияющие на возникновение отклонений. Практический опыт показывает, что каждое обстоятельство или проблема обусловлены несколькими категориями причин. Категории причин, вызывающих отклонения в продуктах программного проекта, в АОЗТ ИДУ обозначены как "Люди", "Инструментальные средства", "Методы", "Процесс". Выбор этих категорий причин продиктован прежде всего тем, что имеющийся практический опыт подтверждает возникновение большинства проблем именно от них. Кроме того, использование категории "Процесс" в причинно-следственном анализе обеспечивает дополнительные возможности в выявлении слабых сторон стандартного процесса. Однако причинно-следственный анализ полезно расширять и проводить, не ограничиваясь лишь приведенным набором категорий. Подойдет любой набор категорий причин, который облегчит нахождение первопричины возникновения отклонений и поможет участникам причинно-следственного анализа в творческом мышлении.

При проведении причинно-следственного анализа в проектной группе в АОЗТ ИДУ используется экранная форма. Изображение этой формы вызывается на экран монитора при нажатии клавиши "Причинно-следственный анализ" в меню отчетов по качеству в системе АСС. В голову рыбьего скелета при причинно-следственном анализе отклонений в качестве следствия автоматически заносится первая слева категория из диаграммы рисунка 7. Если причинно-следственному анализу подвергаются ошибки в продуктах проекта, дефекты в них или дефекты с учетом стоимости их устранения, то в голову рыбьего скелета в качестве следствия помещается первая слева категория из соответствующих диаграмм, которые автоматически генерируются из базы данных отклонений. В голову рыбьего скелета в качестве следствия можно занести и другие данные в зависимости от того, какая проблема подвергается анализу. Для обеспечения такой возможности на экранной форме предусмотрена возможность выбора необходимого для этого следствия. Полученные таким путем заготовки рыбьего скелета в дальнейшем служат основой для проведения причинно-следственного анализа.

В АОЗТ ИДУ причинно-следственный анализ проводится у экрана монитора или с использованием твердых копий заготовок рыбьего скелета при участии полного состава проектной группы. В любом случае причины для анализа выбираются коллективно из диаграммы "Распределение отклонений по причинам за период" (см. рис. 9) и распределяются по костям рыбьего скелета под подходящими категориями. Затем осуществляется поиск ответа на вопрос "чем вызвана эта причина?" и изображение его в виде ветвей диаграммы. Для нахождения первопричины исследуемой проблемы следует искать повторяющиеся причины, сравнивать частоту различных причин и достигать взаимопонимания в команде участников анализа. Причинно-следственный анализ является творческим коллективным процессом, поэтому при его проведении необходимо поощрять любую инициативу к стремлению более глубокого продвижения в поиске первопричин возникновения исследуемых проблем, а также добиваться полного согласия всех членов команды в установлении каждой первопричины.

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

Собрания по причинно-следственному анализу в АОЗТ ИДУ проводятся в каждой проектной группе один раз в месяц в соответствии с формальной процедурой стандартного процесса.

В заключение отметим, что в АОЗТ ИДУ причинно-следственный анализ проводился в течение нескольких лет одновременно в разном количестве проектных групп (максимально в пяти). Результаты проведенных мероприятий из таблицы действий, построенной по данным выполненного причинно-следственного анализа, продемонстрировали, что в тех проектных группах, где наблюдалась тенденция к снижению количества предъявленных отклонений, как в текущем проекте, так и в последующих к причинно-следственному анализу относились серьезно. А в тех проектных группах, где причинно-следственный анализ проводился лишь "для галочки", снижения количества предъявленных отклонений не наблюдалось ни в текущем, ни в последующих проектах. Это наблюдение свидетельствует о том, что причинно-следственный анализ отклонений является эффективным средством повышения качества и самой разработки, и поставляемого ПИ.

Список литературы

1. Boehm B.W. Software Engineering Economics. - Englewood Cliffs: Prentice Hall, 1981. - 767 p. - Русский перевод: Боэм Б.У. Инженерное проектирование программного обеспечения: / Пер. с англ. - М.: Радио и связь, 1985. - 512 с.

2. Six Sigma Producibility Analysis and Process Characterization, by М.J. Harry and J.R. Lawson, Motorola University Press, Chapter 6.

3. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Моро- зов В.П. Предотвращение дефектов при создании программных изделий. // Программные продукты и системы. - 1998. - №2. - С.2-6.

4. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Моро- зов В.П. Процесс разработки программных изделий. - М.: Наука, 2000. - 182 с.

5. Paulk M.C., Curtis В., Chrissis M.B., Weber Ch.V. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. - Pittsburgh: Software Engineering Institute, 1993. - 533 p.

6. Домарацкий А.Н., Домарацкий Я.А. Вероятность обнаружения дефектов во время тестирования программных изделий. // Программные продукты и системы. - 1999. - №4. - С.12-15.

7. "Семь инструментов" управления качеством. / Материалы проекта ISO 9000. http://www.iso9000.ru/.