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

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

Характеристики дефектов:

идентификатор - уникальное имя (номер); должен иметься лёгкий механизм поиска дефекта по идентификатору; не должен изменяться в процессе жизненного цикла проекта.

состояние -показывает этап жизненного цикла дефекта (например: новый, исправленный, закрытый, незакрытый, отклонённый и т.п.)

содержание - текстовое описание, дающее представление о проявлении дефекта. Может содержать ссылки на требования и т.п.

контекст - дефект обычно связан с проектом или задачей; должна указываться версия проекта или задачи;

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

серьёзность- показывает степень влияния проявления дефекта на проект (например: косметический дефект, дефект, вызывающий зависание приложения, вызывающий аварию приложения, вызывающий потерю или нарушение целостности данных).

категория - описывает тип найденного дефекта (например: функциональный дефект, дефект документации, дефект требований и т.п.).

автор- лицо, обнаружившее дефект (тестер, заказчик, пользователь, разработчик и т.п.)

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

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

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

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

дополнительные параметры- резолюция, способы, URL, присоединения

1. Показывает степень влияния проявления дефекта на проект следующая характеристика дефекта:

2. Автор дефекта - это:

Жизненный цикл дефекта.

Подразумевает изменение характеристик дефекта:

- переход из одного состояния в другое;

- изменение ответственного за исправление;

- изменение ответственного за проверку;

- РЕДКО изменение автора;

- изменение контекста;

- РЕДКО изменение серьёзности;

- изменение срочности;

- РЕДКО изменение категории;

- изменение содержания;

- изменение резолюции;

- изменение способа обхода.

Права на изменение отдельных характеристик и отдельные переходы состояний зависят от состояния дефекта, роли сотрудника и политики предприятия

1. Жизненный цикл дефекта подразумевает:

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

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

Коммерческие: IBM Rational ClearQuest, Borland StarTeam, Atlassian JIRA, JetBrainsYouTrack…

Свободнораспространяемые: Mozilla Bugzilla, Trac, Redmine, MantisBT, TUTOS, Интегрированныевсерверыхостингапроектов (например: BitBucket, GitHub).

1. Системы управления дефектов являются:

Команды разработчиков

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

Существует 3 модели команд разработчиков.

Иерархическая.

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

Недостатки: Жёсткость, консервативность, неустойчивость к личным качествам руководителей.

Модель главного программиста.

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

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

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

Модификация 1: объединяются некоторые должности (например, секретарь, редактор и архивариус), но главный программист, второй пилот и администратор- неизменные роли.

Модификация 2: на роль ГП назначается аналитик или менеджер продукта, кодирование ведёт второй пилот, но все принципиальные решения принимает ГП.

Модификация 3: 2 ГП, каждый ГП является так же вторым пилотом по отношению к другому ГП, решения принимаются путём конценсуса.

Модель команды равных.

Действия: (по кругу) управление продуктом, управление программой, разработка, тестирование, сопровождение (логистика), обучение пользователей.

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

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

1. Роли в модели команды главного программиста:

Управление риском в программных проектах: идентификация, анализ, ранжирование

Идентификация рисков- подразумевает формирование списка элементов риска данного проекта по категориям рисков:

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

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

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

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

Ранжирование рисков - подразумевает сортировку рисков пропорционально их влиянию.

1. Формирование списка элементов риска подразумевает:

2. Технические риски связаны:

Управление риском в программных проектах: планирование, разрешение, наблюдение

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

- Строятся зависимости между элементом риска и эталонными уровнями риска;

- Строится план управления каждым элементом риска;

- План интегрируется в общий план проекта.

Разрешение риска - плановое применение действий по уменьшению риска.

Наблюдение - предупреждение цикличности риска, и в случае чего, корректировка.

1. Разрешение риска подразумевает: