Начало работы с RequisitePro

Сразу после запуска RequisitePro появляется небольшая панель (рисунок 25). Она позволяет выполнять общие действия, например, операции с проектами (создавать, удалять, открывать, закрывать, настраивать), операции с пользователями (добавлять, удалять, устанавливать права), операции с документами и требованиями, находящимися в этих документах, и т.д.

С помощью панели RequisitePro происходит запуск трех основных подсистем, которые позволяют:

· Вести обсуждения между участниками проекта (модуль “Discussions”).

· Работать с требованиями непосредственно в базе данных проекта (RequisiteProViews).

· Работать с документами и требованиями в этих документах с помощью MicrosoftWord, который автоматически запускается из-под RequisitePro при открытии любого документа проекта

Рисунок 25 – Основные подсистемы

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

Вопросы

1) Понятие требований. Виды требований.

2) Формирование функциональных требований на основе Use-Case модели.

3) Процесс управления требованиями.

4) Представление требований.

5) Трассировка требований.

6) Показатели качества требований.

7) Что входит в обязанности аналитика?

Дополнительная информация

1) http://www.dpgrup.ru/software-requirements.htm

2) http://habrahabr.ru/post/114571/

3) http://www.interface.ru/home.asp?artId=311

Лекция №9. Тестирование приложений. Функциональное тестирование, нагрузочное тестирование. CASE-средства RationalFunctionalTester, RationalPerformanceTester.

План лекции

-Виды испытаний. ГОСТ 16504, ГОСТ 34.603. Критерии оценки качества систем различного назначения. Документирование испытаний.

-Общее представление о видах тестирования на различных этапах разработки ПО.

-Возможности IBM RationalTeamTest, объектно-ориентированной технологии тестирования.

-Место тестирования в жизненном цикле ПО. Фазы тестирования. Общая схема тестирования.

-Роли и ответственность.

-Методы тестирования («Белый ящик», «Серый ящик», «Черный ящик»). Статические проверки.

-Планирование тестирования.

-Функциональное тестирование ПО с использованием инструментальных средств IBM Rational.

-Нагрузочное тестирование с использованием средств IBM Rational. Основы использования инструментальных средств IBM RationalSoftware в нагрузочных испытаниях программного обеспечения.

Введение

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

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

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

Для обнаружения и устранения ошибок проектирования все этапы разработки и сопровождения ПО должны быть поддержаны методами и средствами систематического автоматизированного тестирования и поэтапных испытаний.

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

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

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

1. Специалисты, управляющие качеством ПО. Они должны владеть:

· методиками и стандартами фирмы, поддерживающими тестирование, контроль, документирование;

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

Должны выявлять:

· все отклонения от заданных параметров качества объектов и процессов;

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

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

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

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

Система стандартизированного документирования частных работ должна обеспечить объективное отражение достигнутого качества компонентов и процессов их создания на всех этапах разработки.

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