Жизненный цикл (ЖЦ) программного обеспечения (ПО)
Жизненный цикл (ЖЦ) программного обеспечения (ПО)
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС):
1. Формирование требований к АС
1. Обследование объекта и обоснование необходимости создания АС
2. Формирование требований пользователя к АС
3. Оформление отчета о выполнении работ и заявки на разработку АС
2. Разработка концепции АС
1. Изучение объекта
2. Проведение необходимых научно-исследовательских работ
3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
4. Оформление отчета о проделанной работе
3. Техническое задание
1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект
1. Разработка предварительных проектных решений по системе и её частям
2. Разработка документации на АС и её части
5. Технический проект
1. Разработка проектных решений по системе и её частям
2. Разработка документации на АС и её части
3. Разработка и оформление документации на поставку комплектующих изделий
4. Разработка заданий на проектирование в смежных частях проекта
6. Рабочая документация
1. Разработка рабочей документации на АС и её части
2. Разработка и адаптация программ
7. Ввод в действие
1. Подготовка объекта автоматизации
2. Подготовка персонала
3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
4. Строительно-монтажные работы
5. Пусконаладочные работы
6. Проведение предварительных испытаний
7. Проведение опытной эксплуатации
8. Проведение приёмочных испытаний
8. Сопровождение АС.
1. Выполнение работ в соответствии с гарантийными обязательствами
2. Послегарантийное обслуживание
Критерии успешности проекта
Критерии успешности проекта— совокупность показателей, которые дают возможность судить о степени успешности выполнения проекта.
Успех проекта,как правило, означает получение всеми заинтересованными сторонами результатов, оправдывающих их ожидания, традиционно формулируемые в виде целей и требований. Если такие цели и требования сформулированы, критериями успешности проекта могут выступать количественные показатели, отражающие степень достижения целей проекта или выполнения определенных требований.
Общий критерий успешности проекта — это достижение целей проекта в запланированное время и в рамках запланированных ресурсов.
Определяющим критерием успешности проекта является актуальность результата на момент его достижения.
В самом начале проекта весьма целесообразно проанализировать причины возможных неудач проекта (потенциальные зоны рисков).
Основными причинами неудач проекта могут быть:
- неясные цели;
- недостаточное финансирование;
- изменение приоритетов бизнеса;
- недостаточная поддержка со стороны высшего руководства;
- неэффективная команда (квалификация персонала проекта);
- недостаточно эффективное взаимодействие в проекте;
- недостаток самоуправления;
- недостаточно эффективные коммуникации;
- отсутствие мотивации (относится к внутренним рискам);
Стратегии конструирования ПО
Существуют 3 стратегии конструирования ПО:
О однократный проход (водопадная стратегия) — линейная последовательность этапов конструирования;
О инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система;
О эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.
Методология быстрой разработки приложений (RAD).
Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
- небольшую команду программистов (от 2 до 10 человек);
- короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
- повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
- фаза анализа и планирования требований;
- фаза проектирования;
- фаза построения;
- фаза внедрения.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
определяется необходимость распределения данных;
производится анализ использования данных;
производится физическое проектирование базы данных;
определяются требования к аппаратным ресурсам;
определяются способы увеличения производительности;
завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
Методология SCRUM
Scrum (от англ. scrum «схватка») ‒ методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки про-граммного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.
Как происходит сама разработка проекта? Сами этапы (спринты) обычно это 30-ти дневные, реже 15-ти дневные или 20-ти дневные этапы, за которые выполняется определенная функциональность, заданная sprint backlogом. При этом, во время работы над спринтом команда самоорганизуется, т.е. все планирование происходит между спринтами. Например, запланировали какой-то набор работ, отправляем команду работать, и в течении спринта ее никто не трогает, она выполняет тот набор требований которые были сказаны. И во время этой работы внутри этой команды происходит самоорганизация, именно поэтому речь идет об аналогиях с системами управления хаосом.
Типы документов.
Вся деятельность организации, предприятия, фирмы, так или иначе, связана с документацией. Документация весьма разнообразна по выполняемым ею функциям, по содержанию и назначению, по степени доступности содержащейся в ней информации. Обобщая цели, задачи и условия документирования, специалисты выделяют ряд факторов, позволяющих разделить все документы на отдельные типы и виды. По фактору адресации документы разделяют на внутреннюю и внешнюю деловую переписку. Внутренняя деловая перепискаведется между должностными лицами, подразделениями одной организации, учреждения. При этом адресант и адресат документа состоят в отношениях должностного соподчинения. Документацию этого типа называют служебной. Внешняя деловая перепискаведется между разными организациями, учреждениями, должностными и частными лицами, не состоящими в прямом подчинении по отношению друг к другу. Документы, которыми обмениваются организации, называют официальными письмами. По содержанию и назначению выделяют распорядительные, отчетные, справочные, плановыеи другие виды документов, каждый из которых характеризуется общностью требований, предъявляемых к содержанию и языковому оформлению. В зависимости от того, к какой сфере человеческой деятельности относится документируемая информация, различают управленческие, научные, технические, производственные, финансовыеи другие виды документов. По фактору доступности документируемой информации документы могут быть открытого пользования (доступа), ограниченного доступа и конфиденциального характера. |
Связи между ролями
Роли делятся на два класса – основные и дополнительные.
Основные роли – это роли, которые есть практически во всех проектах. А дополнительные включаются в проект по мере необходимости, если проект имеет какую-то определенную специфику.
Заказчик– это тот человек, который ставит задачу, платит деньги и в результате принимает готовую работу.
Планировщик ресурсов – это руководящее лицо компании разработчика, принимающее организационные и финансовые решения. В самой разработке участие не принимает, но управляет всей политикой компании и разработкой в частности.
Менеджер проекта – это менеджер среднего звена управления, который управляет какой-то конкретной группой, например, либо разработчиков, либо тестировщиков. Его задача принимать определенные управленческие решения по продвижению проекта.
Архитектор – человек ответственный за выработку проектных решений и создание архитектуры.
Руководитель команды (не всегда такая роль присутствует) – это выделенный разработчик (самый опытный), который руководит небольшой группой разработки.
Разработчик - тот кто собственно разрабатывает идеи придуманные архитектором.
Тестер или тестеровщик – человек, который тестирует созданные группами разработчиков артефакты, например, программы.
Разработчик документации – человек, который формирует необходимую программно-эксплуатационную документацию.
И еще две роли. Первая – это пользователь. Он не обязательно входит в команду разработки, он не обязательно является заказчиком, но это тот человек, который по сути использует систему в своей повседневной жизни.
Инженер группы поддержки – это человек, который уже на этапе выпуска проекта обеспечивает последнюю стадию ЖЦ и помогает, в том числе, пользователям работать с системой и улучшать систему.
Программные проекты
Проект-самостоятельно управляемый объект разработки. Результат программного проекта-программный продукт. Для того, чтобы добиться этой цели – создание этого самого продукта, программный проект проходит разные этапы ЖЦ и при этом разработчиками выполняются различные проектные активности.
Все разработчики выполняют различные работы.
Первое – это задачи или подпроекты(программного проекта, которые являются обособленными и с которыми связан определенный набор требований)
Вторая часть проектной активности – это изменения,которые происходят с требованиями. исправление дефектов.
Вот это три активности, которые обычно выполняются разработчиками.
Первая активность – это задачи( тот элемент программного проекта, который выдается на выполнение какому-то одному разработчику)
Активность – изменение проекта.
Обычно программный проект делят на этапы,т.е. когда проект делится на этапы то это тот верхний уровень проекта, в котором в том числе участвует заказчик и к нему привязывают всякие важные моменты: приемо-сдаточные испытания, финансовые вопросы и т.д.
С этапом связаны ключевые действия, ключевые решения, которые может принять заказчик и исполнитель по поводу дальнейшего продвижения проекта. В программных проектах веха – это небольшая законченная часть какого-либо этапа работы. Обычно вехи формулируются таким образом, чтобы их можно было наблюдать и контролировать. По вехам менеджер может определять успешность всего проекта в целом.
Т.е. для наблюдения за проектом кроме визуального наблюдения нам требуются еще какие-либо отчеты о разных аспектах состояния проекта.
Для этого мы пытаемся получать текущие срезы проекта.Т.е. это разные срезы, которые позволяют смотреть на выполнение одной или нескольких задач.
Срез по сотрудникам
срез по дефектам.
срез по критическому пути,т.к. этот путь влияет на общее выполнение проекта. И знание, что у нас происходит с задачами, которые находятся на критическом пути позволяют нам прогнозировать риски, которые могут произойти.
Проектные активности
Для того, чтобы добиться этой цели – создание этого самого продукта, программный проект проходит разные этапы ЖЦ и при этом разработчиками выполняются различные проектные активности.
Все разработчики выполняют различные работы. Что это за работы?
Первое – это задачи или подпроекты, или просто работы. Это части программного проекта, которые являются обособленными и с которыми связан определенный набор требований. Обычно конкретные задачи выполняются какими-то конкретными разработчиками.
Вторая часть проектной активности – это изменения,которые происходят с требованиями.
И еще одна вещь, которой может заниматься разработчик – это исправление дефектов.
Вот это три активности, которые обычно выполняются разработчиками.
Это средства по деятельности. А какие есть средства по времени?
Обычно, когда говорят про временные сущности проекта, то говорят про два типа временных сущностей: этапы – это крупная временная сущность, длящаяся несколько недель, месяцев или даже годы и обычно формирующая законченную часть проекта.
Второй тип: вехи – это меньшая временная сущность, которая формирует какую-то функциональность.
Первая активность – это задачи.
Обычно задача – это тот элемент программного проекта, который выдается на выполнение какому-то одному разработчику.
Какими свойствами характеризуется задача? Их м.б. много, но чаще всего интересуют временные характеристики.
Какие м.б. временные связи между задачами?
Когда весь граф последовательностей задач построен у нас не д.б. циклических связей.
Активность – изменение проекта.
Последняя активность – это исправление программных дефектов.
В отличие от всего предыдущего эту активность очень трудно запланировать, включить в проектный план заранее. Это как раз те виды работ, которые могут проектный план подвинуть.
Поэтому, когда формируется план работ надо всегда учитывать временные запасы по всем путям развития проекта, чтобы можно было выделить время на исправление ошибок не изменив все время работы. Если же у нас никаких запасов и критический путь, в котором не предусмотрено время на исправление дефектов в таком случае проект будет сорван.
Теперь рассмотрим вторую группу сущностей – это временные сущности.
Обычно программный проект делят на этапы.
Т.е. когда проект делится на этапы то это тот верхний уровень проекта, в котором в том числе участвует заказчик и к нему привязывают всякие важные моменты: приемо-сдаточные испытания, финансовые вопросы и т.д.
С этапом связаны ключевые действия, ключевые решения, которые может принять заказчик и исполнитель по поводу дальнейшего продвижения проекта. Что это за решения?
Т.е. если финансовые, временные показатели удовлетворяют заказчика, то проект может продолжаться.
Т.е.этап– это крупныйвременной промежуток, состоящий в решении ограниченного круга задач, подчиненных какой-то цели.
Если говорить о более мелких других временных сущностях, то это в первую очередь веха проекта (milеstone – это придорожный камень на котором указывается расстояние до следующего камня, а в России это называлось верста или верстовой столб).
В программных проектах веха – это небольшая законченная часть какого-либо этапа работы. Обычно этих майлстоунов в проекте довольно таки много. Обычно вехи формулируются таким образом, чтобы их можно было наблюдать и контролировать. По вехам менеджер может определять успешность всего проекта в целом.
Сама веха не является отдельным задачным этапом проекта.
Временные сущности
Теперь рассмотрим вторую группу сущностей – это временные сущности.
Обычно программный проект делят на этапы.
Т.е. когда проект делится на этапы то это тот верхний уровень проекта, в котором в том числе участвует заказчик и к нему привязывают всякие важные моменты: приемо-сдаточные испытания, финансовые вопросы и т.д.
С этапом связаны ключевые действия, ключевые решения, которые может принять заказчик и исполнитель по поводу дальнейшего продвижения проекта.
Т.е. если финансовые, временные показатели удовлетворяют заказчика, то проект может продолжаться.
Т.е.этап– это крупныйвременной промежуток, состоящий в решении ограниченного круга задач, подчиненных какой-то цели.
Если говорить о более мелких других временных сущностях, то это в первую очередь веха проекта.
В программных проектах веха – это небольшая законченная часть какого-либо этапа работы. Обычно этих майлстоунов в проекте довольно таки много. Обычно вехи формулируются таким образом, чтобы их можно было наблюдать и контролировать. По вехам менеджер может определять успешность всего проекта в целом.
Два основных временных параметра, которые используются в разных проектах– вехаиэтап.Все это вместе с активностями и проектными ресурсами относится к выполнению проекта.
Определение рисков
Определение рисков – первая стадия процесса управления рисками. На этой стадии описываются риски, которые могут проявиться при реализации проекта. В принципе на этой стадии не должна оцениваться вероятность и значимость рисков, но на практике маловероятные риски с незначительными последствиями обычно отбрасываются сразу.
Определение рисков может выполняться в режиме командной работы с использованием подхода "мозговой штурм" либо основываться на опыте менеджера. При определении рисков может помочь приведенный ниже список возможных категорий рисков.
1. Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система.
2. Риски, связанные с персоналом. Связаны с членами команды разработчиков.
3. Организационные риски. Проистекают из организационного окружения, в котором выполняется проект.
4. Инструментальные риски. Связаны с используемыми CASE-средствами и другими средствами поддержки процесса создания ПО.
5. Риски, связанные с системными требованиями. Проявляются при изменении требований, предъявляемых к разрабатываемой системе.
6. Риски оценивания. Связаны с оцениванием характеристик программной системы и ресурсов, необходимых для реализации проекта.
- Анализ риска
При анализе для каждого определенного риска подсчитывается вероятность его проявления и ущерб, который он может нанести. Не существует простых методов выполнения анализа рисков – в значительной мере он основан на мнении и опыте менеджера. Не претендуя на исключительную точность, можно привести следующую шкалу вероятностей рисков и их последствий.
1. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.
2. Возможный ущерб от рисковых ситуаций можно подразделить на катастрофический, серьезный, терпимый и незначительный
Разрешение риска
Планирование рисков
Планирование заключается в определении стратегии управления каждым значимым риском, отобранным для мониторинга после анализа рисков. Здесь также не существует общепринятых подходов для разработки таких стратегий – многое основывается на "чутье" и опыте менеджера проекта
Существует три категории стратегий управления рисками.
1. Стратегии предотвращения рисков. Согласно этим стратегиям следует проводить мероприятия, снижающие вероятность проявления рисков. Примером может служить стратегия исключения потенциально дефектных компонентов, описанная в табл. 4.
2. Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчиков (см. табл. 4).
3. Планирование "аварийных" ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой ситуации. В табл. 4 это стратегия поведения при возникновении финансовых проблем у организации-разработчика.
Наблюдение за риском
Мониторинг рисков
Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести. Для этого необходимо постоянно отслеживать факторы, которые влияют на вероятность рисков и возможный ущерб. Эти факторы зависят от типов риска. В табл. 5 приведены признаки, которые помогают определить тип риска.
Мониторинг рисков должен быть непрерывным процессом, отслеживающим ход выполнения мероприятий по управлению рисками, при этом каждый основной риск должен рассматриваться отдельно.
Наблюдение за риском
Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести. Для этого необходимо постоянно отслеживать факторы, которые влияют на вероятность рисков и возможный ущерб. Эти факторы зависят от типов риска. В табл. 5 приведены признаки, которые помогают определить тип риска.
Таблица 5. Признаки рисков
Тип риска | Признаки |
Технологические риски | Задержки в поставке оборудования или программных средств поддержки процесса создания ПО, многочисленные документированные технологические проблемы |
Риски, связанные с персоналом | Низкое моральное состояние персонала, натянутые отношения между членами команды разработчиков, низкое качество выполненной работы |
Организационные риски | Разговоры среди персонала о пассивности и недостаточной компетентности высшего руководства организации |
Инструментальные риски | Нежелание разработчиков использовать программные средства поддержки, неодобрительные отзывы о CASE-средствах, запросы на более мощные инструментальные средства |
Риски, связанные с системными требованиями | Необходимость пересмотра многих системных требований, недовольство заказчика ПО |
Риски оценивания | Изменения графика работ, многочисленные отчеты о нарушении графика работ |
Мониторинг рисков должен быть непрерывным процессом, отслеживающим ход выполнения мероприятий по управлению рисками, при этом каждый основной риск должен рассматриваться отдельно.
Характеристики дефектов
Дефект – обнаруженная в процессе разработки, тестирования или эксплуатации ошибка в разрабатываемом приложении.
К понятию риски относятся негативные события и их величины, отражающие потери, убытки или ущерб от процессов или продуктов, вызванные дефектами при проектировании требований, недостатками обоснования проектов ПС, а также при последующих этапах разработки, реализации и всего жизненного цикла комплексов программ.
Риски проявляются, как негативные последствия дефектов функционирования и применения ПС, которые способны вызвать ущерб системе, внешней среде или пользователю, в результате отклонения характеристик объектов или процессов, от заданных требованиями заказчика, согласованными с разработчиками.
Оценки качества программных средств могут проводиться с двух позиций: с позиции положительной эффективности и непосредственной адекватности их характеристик назначению, целям создания и применения, а также с негативной позиции возможного при этом ущерба – риска от использования ПС или системы.
Показатели качества преимущественно отражают положительный эффект от применения системы или ПС и основная задача разработчиков проекта состоит в обеспечении высоких значений качества. Риски характеризуют возможные негативные последствия дефектов или ущерб пользователей при применении и функционировании ПС и системы, и задача разработчиков сводится к сокращению дефектов и ликвидации рисков.
Характеристики дефектов и рисков непосредственно связаны с достигаемой корректностью, безопасностью и надежностью функционирования программ и помогают:
- оценивать реальное состояние проекта и планировать необходимую трудоемкость и длительность для его положительного завершения;
- выбирать методы и средства автоматизации тестирования и отладки программ, адекватные текущему состоянию разработки и сопровождения ПС, наиболее эффективные для устранения определенных видов дефектов и рисков;
- рассчитывать необходимую эффективность контрмер и дополнительных средств оперативной защиты от потенциальных дефектов и не выявленных ошибок;
- оценивать требующиеся ресурсы ЭВМ по расширению памяти и производительности, с учетом затрат на реализацию контрмер при модификации и устранении ошибок и рисков.
Понятие ошибки в программе – в общем случае под ошибкой подразумевается неправильность, погрешность или неумышленное искажение объекта или процесса, что может быть причиной ущерба – риска при функционировании и применении программы
Идентификатор дефекта.
ИДЕНТИФИКАЦИЯ ДЕФЕКТА – распознавание дефекта и оценка
его значимости в пределах системы.
Проект дефекта
Срочность дефекта
Категория дефекта
Серьезность дефекта
Автор дефекта
Состояние дефекта
Дефект – обнаруженная в процессе разработки, тестирования или эксплуатации ошибка в разрабатываемом приложении.
При регистрации дефекта он приобретает статус Open, резолюция Unresolved. Лидер команды разработки или менеджер проекта (в некоторых случаях и лидер команды тестирования) выставляет приоритет дефекта и назначает разработчика ответственного за выполнение задачи.
Разработчик, когда берется за исполнение дефекта, меняет статус сущности на In Progress, резолюция остается Unresolved. Нежелательна ситуация, когда один и тот же разработчик имеет более одной задачи на исправление в статусе In Progress.
Менеджер проекта, руководители подразделений до назначения разработчика на исправление или ответственный разработчик после детального изучения проблемы могут поменять статус дефекта с OpenилиIn ProgressнаResolvedв случаях:
· Описанный дефект не может быть устранен, описанный случай не является дефектом, данную проблему не нужно устранять. В данном случае выставляется резолюция Won‘t Fixи адресуется создателю отчета. Отчет должен сопровождаться комментарием с информацией о причинах закрытия дефекта. Создатель отчета или любой другой представитель команды тестирования переводит статус дефекта с ResolvedнаTesting. Резолюция остается прежней. После исследования специалист по тестированию закрывает дефект, статус меняется с TestingнаClosed. Резолюция остается прежней. Никто кроме представителей отдела тестирования не может самостоятельно закрыть дефект. Специалист по тестированию может повторно открыть дефект, предоставив аргументацию с причинами необходимости исправления. Статус меняется с TestingнаReopened,резолюция меняется с Won‘t Fixна Unresolved.
· Данный дефект дублирует уже существующий. В данном случае выставляется резолюция Duplicate и адресуется создателю отчета. Автор отчета или любой другой представитель команды тестирования переводит статус дефекта с ResolvedнаTesting. Резолюция остается прежней. Должна быть установлена связь между дефектами. После того, как создатель отчета или руководитель команды тестирования убедился, что данные отчеты действительно являются дублирующими, дефект должен быть закрыт, статус меняется с Testing наClosed. Резолюция остается прежней. В случае если дефект не является дублирующим, то он должен быть возвращен команде разработки. Статус меняется с Testing наReopened,резолюция меняется с Duplicateна Unresolved. Никто кроме представителей команды тестирования не может самостоятельно закрыть дефект.
· Описанная ситуация не воспроизводится. В данном случае выставляется резолюция CannotReproduce и адресуется создателю отчета. Автор отчета пытается воспроизвести ошибку. Статус дефекта меняется с ResolvedнаTesting. Резолюция остается прежней. Если дефект воспроизводится, специалист по тестированию детализирует описание проблемы, указывает дополнительную информацию. Статус меняется с TestingнаReopened,резолюция меняется с Cannot Reproduceна Unresolved.Дефект должен быть возвращен разработчику. В случае, если описанная ситуация не воспроизводится и у специалиста по тестированию, то создатель отчета или руководитель команды тестирования закрывает дефект, статус меняется с Testing наClosed. Резолюция остается прежней. Никто кроме представителей команды тестирования не может самостоятельно закрыть дефект.
Примечание: в некоторых процессах разработки изначальный статус созданного дефекта является New. После одобрения менеджера или руководителя комнады тестирования статус дефекта меняется наOpen. После назначения разработчика на исправление статус меняется с Openна Assigned.
После устранения дефекта разработчик выставляет версию приложения, для которой будет доступно исправление. Статус дефекта должен быть изменен с In Progressна Resolved.Резолюция меняется с Unresolvedна Fixed. Разработчик снимает назначение с себя на создателя отчета. В комментарии разработчик должен указать всю важную информацию по исправлению. Если создатель отчета не является участником проекта тестирования, то назначение адресуется лидеру команды тестирования, который, назначает ответственного специалиста по тестированию за верификацию дефекта.
Желательно, чтобы проверку исправления выполнял создатель отчета о дефекте (если автор является участником команды тестирования).
Специалист по тестированию, назначенный на проверку исправления переводит статус дефекта в Testing, резолюция остается прежней.
После окончания проверки исправления, в случае если дефект исправлен корректно, то статус дефекта меняется с TestingнаClosed. Резолюция меняется с Fixed на Verified.
В случае если дефект не исправлен или исправлен в не полном объеме, то статус дефекта меняется с Testingна Reopened,резолюция меняется сFixedнаUnresolved.Назначение адресуется разработчику, работавшему над исправлением проблемы. В случае возврата ошибки специалист по тестированию должен указать комментарием причину ошибку и версию приложения, для которого производилась проверка исправления. Жизненный цикл дефекта повторяется.
Из состояния Closed дефект может быть открыт повторно, в случае его повторного проявления. Статус выставляется Reopened, резолюция Unresolved.
Зависимости дефекта
Дефект – обнаруженная в процессе разработки, тестирования или эксплуатации ошибка в разрабатываемом приложении.
Можно разделить ошибки на три уровня:
Небольшими ошибками называют такие, на которые средний пользователь не обратит внимания при применении ПС, вследствие отсутствия их проявления, и последствия которых обычно так и не обнаруживаются. Небольшие ошибки могут включать орфографические ошибки на экране, пропущенные разделы в справочнике и другие мелкие проблемы. Такие ошибки никогда не помешают выпуску и применению версии системы и программного продукта. По десятибалльной шкале рисков небольшие ошибки находятся в пределах от 1 до 3 приоритета (см. ниже).
Умеренными ошибками называют те, которые влияют на конечного пользователя, но имеются слабые последствия или обходные пути, позволяющие сохранить достаточную функциональность ПС. Это такие дефекты, как неверные ссылки на страницах, ошибочный текст на экране и даже сбои, если эти сбои трудно воспроизвести, и они не оказывают влияния на существенное число пользователей. Некоторые умеренные ошибки, возможно, проникают в конечный программный продукт. Ошибки, которые можно исправить на этом уровне, следует исправлять, если на это есть время и возможность. По десятибалльной шкале умеренные ошибки находятся в диапазоне от 4 до 7 приоритета.
Критические ошибки останавливают выпуск версии программного продукта. Это могут быть ошибки с высоким влиянием, которые вызывают сбой в системе или потерю данных, отражаютс