'

Управление требованиями и тестирование ПО Начальник отдела тестирования Якимович Алексей

Понравилась презентация – покажи это...





Слайд 0

Управление требованиями и тестирование ПО Начальник отдела тестирования Якимович Алексей


Слайд 1

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


Слайд 2

Содержание Введение в общий процесс разработки и анализа требований Практические аспекты разработки требований Процесс рецензирования требований


Слайд 3

1. Введение в общий процесс разработки и анализа требований.


Слайд 4

V-модель разработки и тестирования


Слайд 5

Управление изменениями При внесении изменения необходимо выполнить следующую работу: Принять или отклонить изменение Согласовать изменение с заказчиком Организовать работы по переделке


Слайд 6

Создание и анализ связей между требованиями (1) В контексте бизнеса связи показываются как: Стратегии бизнеса конкретизируются как Задачи бизнеса которые воплощаются как Организация бизнеса и бизнес процессов


Слайд 7

Создание и анализ связей между требованиями (2) В контексте системного проектирования связи показываются как: Пользовательские требования (stakeholder requirements) удовлетворяются Системные требования которые разделяются на Подсистемы которые реализуются как Компоненты


Слайд 8

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


Слайд 9

Создание и анализ связей между требованиями (3) Стрелка указывает источник информации!


Слайд 10

Создание и анализ связей между требованиями (4) Методы анализа связей требований


Слайд 11

Создание и анализ связей между требованиями (6)


Слайд 12

Создание и анализ связей между требованиями (6)


Слайд 13

Требования в области проблем и в области решений(1)


Слайд 14

Требования в области проблем и в области решений(2) Отсутствие разделения между проблемами и решениями может привести к следующим негативным последствиям: Недостаточное понимание существующих проблем Невозможность определить границы (scope) системы, т.е. невозможно понять, какой функционал должен входить, а какой- нет Доминирование разработчиков в дискуссиях о системе, поскольку единственные известные требования формулируют в терминах реализации, а не в терминах проблем Невозможность нахождения наилучшего решения из-за ограничения свободы в выборе решения Вывод: Нужно жестко отделять описания проблем от решений!


Слайд 15

Стратегия проверки(1) Связи типа «удовлетворяет/удовлетворяется» отражают процесс получения производных требований из входящих требований. Стратегия проверки- это набор проверочных мероприятий, проверяющих удовлетворенность требованиий. Каждая проверка подразумевает следующие аспекты: тип проверки фаза, когда проверка осуществляется тестовый стенд для проверки критерий успеха


Слайд 16

Требования и тестирование


Слайд 17

Стратегия проверки(2)


Слайд 18

Простой метод анализа требований - CRUD Для любого объекта должны быть известны ответы на следующие вопросы: Create - Кто и как создает объект? Read - Как и где можно прочитать информацию об объекте? Update - Кто и как может изменить информацию об объекте? Delete – Кто и как может удалить объект?


Слайд 19

Нефункциональные требования – FURPS+ Functionality - Feature set, Capabilities, Generality, Security Usability - Human factors, Aesthetics, Consistency, Documentation Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure Performance - Speed, Efficiency, Resource consumption, Throughput, Response time Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Portability, Localizability + Requirements for Design , Implementation, Interface, etc “Плохой архитектор проектирует функциональные требования, а хороший- нефункциональные… “ Можно продолжить: “Плохой аналитик/тестировщик …..”))


Слайд 20

2. Практические аспекты разработки требований .


Слайд 21

Требования к требованиям Требования должны предоставлять следующие возможности: Однозначная идентификация Классификация - по важности, типу, срочности в реализации,…. Статус с разных точек зрения – рецензирования, удовлетворения, проверки,.. Анализировать каждое требование в контексте документа, т.е. в окружении других требований Нахождения требования по контексту, классификации и другим признакам Установления связей между требованиями …


Слайд 22

Приложения для разработки требований Оптимальные приложения для работы с требования должны совмещать преимущества баз данных и текстовых документов! Например: Rational Requisite Pro 8.0, Telelogic Doors…


Слайд 23

Понятие «Ключевых требований» Key User Requirement (KUR) или Key Performance Indicators (KPI) Ключевое Требование подразумевает отрицательный ответ на вопрос: На пользовательском уровне: «Если решение не предполагает <эту> возможность (функцию, опцию, т.д.), стану ли я в этом случае ее приобретать?» На системном уровне: «Если система не обеспечивает <этого>, будет ли система все еще нужна мне?» Ключевые требования позволяют держать в фокусе цели и задачи проекта. Обсуждение/изменение ключевых требований должно происходить с большим вниманием и осторожностью.


Слайд 24

Элементарные связи


Слайд 25

Расширенные связи с аргументом удовлетворения Расширенные связи & - и (conjunction)– для реализации аргумента удовлетворения нужно выполнение всех требований or - или (disjunction) – для реализации аргумента удовлетворения нужно выполнение любого из требований = - требование может быть «спущено» без изменений на более низкие уровни


Слайд 26

Классификация Требований Первичная классификация – место в контексте документа. Множественная вторичная классификация по следующим группам: Идентификация, Характеристики, Приоритет/Важность, Источник и владелец, Контекст, Процессы и Статусы, … Введение классификации с начала работы с требованиями не требует больших трудозатрат. Классификация упрощает анализ требований на непротиворечивость, полноту, связанность и согласованность.


Слайд 27

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


Слайд 28

Рецензирование требований На что обращать внимание: Хаос – требование должно быть сконцентрировано на самом важном «Лазейки» - например фраза «если это необходимо» Более одного требования в одном параграфе (союз И знак!) Рассуждения Размытые понятия и слова – напр.- часто, нормально, типично, т.п. Неопределенные термины – удобный, универсальный, гибкий Желаемое выдано за требуемое – напр. 100% надежный, приятный для пользователей, безопасный, обрабатывать неожиданные сбои, не должен никогда ломаться, и тп


Слайд 29

3. Процесс рецензирования требований .


Слайд 30

Процесс рецензирования


Слайд 31

Не допускается рецензирование черновиков документов. Обсуждение замечаний на общем собрании – не более 2х минут. Инспектор следит за готовностью документа к рецензированию. В рецензировании может участвовать заказчик + вся команда исполнителей! + приглашенные эксперты. Обязательная проверка внесения изменений. Не нужно изобретать велосипед. Процедура хорошо прописана и известна -www.processimpact.com/reviews_book/. Можно использовать ПО для организации процесса рецензирования, но лучше иметь еще и личные встречи. Рецензирование документации


Слайд 32

Вопросы ?


Слайд 33

Контактная информация AliakseiYakimovich@iba.by


×

HTML:





Ссылка: