7 лекция портала IT-JOB. Алексей Якимович, начальник отдела тестирования интернет-подразделения IBA

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

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

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

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

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

11. Создание и анализ связей между требованиями (4) Методы анализа связей требований Методы анализа Описание Поддерживаемый процесс Анализ влияния Что будет если изменить это требование? Управление изменениями Анализ последствий Нам это действительно нужно? Анализ экономической целесообразности Анализ покрытия Все ли учтено? Проектирование, отчетность по прогрессу

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

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

14. Требования в области проблем и в области решений(1) Уровень требований Область Точка зрения Цель Пользовательские требования Область проблем Пользователь ( представитель заинтересованной стороны) Определяет - ЧТО пользователь желает достичь с помощью создаваемой системы. Избегаем решений! Системные требования Область решения Аналитик Абстрактно определяет – КАК система будет удовлетворять пользовательским требованиям. Системные спецификации (архитектура системы) Область решения Архитектор Определяет – КАК конкретная архитектура системы будет удовлетворять системным требованиям.

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

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

19. Простой метод анализа требований - CRUD Для любого объекта должны быть известны ответы на следующие вопросы: C reate - Кто и как создает объект? R ead - Как и где можно прочитать информацию об объекте? U pdate - Кто и как может изменить информацию об объекте? D elete – Кто и как может удалить объект?

20. Нефункциональные требования – FURPS + F unctionality - Feature set, Capabilities, Generality, Security U sability - Human factors, Aesthetics, Consistency, Documentation R eliability - Frequency/severity of failure, Recoverability, P redictability, Accuracy, Mean time to failure P erformance - Speed, Efficiency, Resource consumption, Throughput, Response time S upportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Portability, Localizability + R equirement s for Design , Implementation , I nterface , etc “ Плохой архитектор проектирует функциональные требования, а хороший- нефункциональные… “ Можно продолжить: “ Плохой аналитик/тестировщик ….. ” ))

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

23. Приложения для разработки требований Оптимальные приложения для работы с требования должны совмещать преимущества баз данных и текстовых документов! Например: Rational Requisite Pro 8.0, Telelogic Doors … Базы Данных Текстовый Документ Преимущества : Легко Нумеровать, Классифицировать, Трассировать, Сортировать, Отслеживать изменения… Качество отдельного требования высокое! Преимущества : Видение всего документа в целом. Качество документа в целом высокое! Недостаток: Теряется целостность видения документа. Качество всего документа низкое!! Недостаток: Неудобно нумеровать, классифицировать, и т.д Качество отдельного требования низкое! Примеры: Enterprise Architect, Rational Requisite Pro 6.0,… MS Word)

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

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

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

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

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

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

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

33. Вопросы ?

34. Контактная информация [email_address]