- •230100.62 (09.03.01) «Информатика и вычислительная техника» профиля подготовки «Программное обеспечение вычислительной техники и
- •231000.62 (09.03.04) «Программная инженерия» профиля подготовки «Разработка программно-информационных систем»
- •1) 230100.62 (09.03.01) «Информатика и вычислительная техника»:
- •2) 231000.62 (09.03.04) «Программная инженерия»:
- •Лекция №1. Основные понятия и определения
- •Лекция №2. Прикладной системный анализ при разработке по. Принципы структурного анализа. Процедура требований.
- •2.1 Проблема сложности ис
- •2.2 Основные понятия структурного анализа
- •2.3 Принципы структурного анализа
- •2.4 Группы средств структурного анализа и их взаимоотношения
- •2.5 Краткий список структурных методологий по группам средств моделирования
- •Лекция №3. Моделирование функций по. Нотация idef0. Case-средство bpWin
- •3.1 Диаграммы idef0
- •3.2 Виды связей в idef0
- •3.3 Диаграмма дерева узлов
- •3.4 Case-средство bpWin
- •Лекция №4. Описание динамики системы. Нотация idef3
- •4.1 Основные символы idef3
- •4.2 Виды связей в idef3
- •4.3 Пример диаграммы idef3
- •Лекция №5. Постановка требований к данным. Словари данных. Моделирование данных в нотации idef1x. Case-средство erWin
- •5.1 Словарь данных
- •5.2 Определение структуры данных для информационных потоков
- •5.3 Моделирование данных в нотации idef1x
- •5.3.1 Базовые понятия erd
- •5.3.2 Виды сущностей в idef1x
- •5.3.3 Виды связей в idef1x
- •Лекция №6. Стандарт онтологического исследования idef5
- •6.1 Основные принципы онтологического анализа
- •6.2 Концепции idef5
- •6.3 Язык описания онтологий в idef5
- •6.4 Виды схем и диаграмм idef5
- •Лекция №7. Постановка требований к интерфейсу по. Понятие Usability.
- •7.1 Эргономические цели и показатели качества программного продукта
- •7.2 Проблемы, возникающие на этапе разработки прототипа gui и варианты их решения
- •7.3 Принципы реализации пользовательского интерфейса
- •Лекция №8. Управление требованиями к программному продукту. Case-средство Requisite Pro.
- •8.1 Нормативная основа
- •8.2 Основные положения
- •8.2.1 Цели управления требованиями
- •8.2.2 Участники управления требованиями
- •8.2.3 Политика в области управления требованиями
- •8.3 Обеспечение процессов управления требований
- •8.3.1 Распределение ответственности
- •8.4 Действия по управлению требованиями
- •8.4.1 Анализ требований
- •8.4.2 Разработка материалов проекта на основе требований
- •8.4.3 Контроль изменений требований
- •8.5 Измерения
- •8.6.2 Контроль со стороны руководителя проекта
- •8.6.3 Контроль со стороны гок
- •8.7 Стандарт оформления требований
- •8.7.1 Шаблон для разработки требований
- •8.7.2 Правила оформления требований
- •8.7.3 Структурирование требований
- •8.8 Показатели качества требований
- •8.9 Начало работы с RequisitePro
- •Лекция №9. Тестирование приложений. Функциональное тестирование, нагрузочное тестирование. Case-средства Rational Functional Tester, Rational Performance Tester.
- •9.1 Дестабилизирующие факторы и методы обеспечения высокого качества функционирования по
- •9.2 Использование среды автоматизированного тестирования Platinum testBytes
- •9.3 Методы обеспечения качества и надежности программных средств
- •9.4 Использование case для повышения качества по
- •9.5 Влияние стандартов открытых систем на качество по
- •9.6 Повышение качества по путем тестирования
- •9.6.1 Основные особенности процесса тестирования по
- •9.6.2 Организационные особенности тестирования
- •9.6.3 Сертификация по
- •9.6.4 Организация и планирование тестирования для обеспечения качества по
- •9.7 Важнейшие разделы iso 9003
- •Документирование системы качества
- •Корректирующие действия
- •Лекция №10. Стандарты, регламентирующие разработку по
- •10.1 Стандарт iso 12207:1995
- •10.3 Серия стандартов гост 34-ххх «Информационная технология»
- •Заключение
- •Библиографический список
- •Приложения Приложение а. Перечень ключевых слов
- •660049, Г. Красноярск, пр. Мира, 82
8.9 Начало работы с RequisitePro
Сразу после запуска RequisitePro появляется небольшая панель (рисунок 25). Она позволяет выполнять общие действия, например, операции с проектами (создавать, удалять, открывать, закрывать, настраивать), операции с пользователями (добавлять, удалять, устанавливать права), операции с документами и требованиями, находящимися в этих документах, и т.д.
С помощью панели RequisitePro происходит запуск трех основных подсистем, которые позволяют:
Вести обсуждения между участниками проекта (модуль “Discussions”).
Работать с требованиями непосредственно в базе данных проекта (RequisitePro Views).
Работать с документами и требованиями в этих документах с помощью Microsoft Word, который автоматически запускается из-под 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-средства Rational Functional Tester, Rational Performance Tester.
План лекции
Виды испытаний. ГОСТ 16504, ГОСТ 34.603. Критерии оценки качества систем различного назначения. Документирование испытаний.
Общее представление о видах тестирования на различных этапах разработки ПО.
Возможности IBM Rational TeamTest, объектно-ориентированной технологии тестирования.
Место тестирования в жизненном цикле ПО. Фазы тестирования. Общая схема тестирования.
Роли и ответственность.
Методы тестирования («Белый ящик», «Серый ящик», «Черный ящик»). Статические проверки.
Планирование тестирования.
Функциональное тестирование ПО с использованием инструментальных средств IBM Rational.
Нагрузочное тестирование с использованием средств IBM Rational. Основы использования инструментальных средств IBM Rational Software в нагрузочных испытаниях программного обеспечения.
Введение
Для удовлетворения высоких требований к функционированию ПО необходимо выделение задач и работ по обеспечению качества программ, а также обучение разработчиков и концентрация их усилий на решении таких задач.
Для каждого проекта программного обеспечения, выполняющего ответственные функции, должны разрабатываться и применяться специальный план и программа, методология и инструментальные средства, обеспечивающие требуемые качество, надежность и безопасность.
Для обеспечения качества программных средств в конкретных проектах должны быть организованы и стимулированы разработка, освоение и применение современных автоматизированных технологий и инструментальных средств, обеспечивающих предупреждение или исключение большинства видов дефектов или ошибок при создании и модификации ПО и его компонентов.
Для обнаружения и устранения ошибок проектирования все этапы разработки и сопровождения ПО должны быть поддержаны методами и средствами систематического автоматизированного тестирования и поэтапных испытаний.
Для проверки достигнутого качества, надежности и безопасности применения сложных, критических программных продуктов служит их обязательная сертификация в аттестованных проблемно-ориентированных сертификационных лабораториях.
Непредсказуемость вида, места и времени проявления дефектов ПО в процессе эксплуатации приводит к необходимости создания специальных, дополнительных систем автоматической оперативной защиты от непредумышленных, случайных искажений вычислительного процесса, программ и данных. Оперативная защита за счет временной, программной и информационной избыточности позволяет выявить и блокировать распространение негативных последствий проявления дефектов и уменьшить их влияние на качество функционирования ПО до устранения первопричины дефекта.
Первоочередными мерами по обеспечению качества ПО является воспитание и обучение следующих двух категорий специалистов:
Специалисты, управляющие качеством ПО. Они должны владеть:
методиками и стандартами фирмы, поддерживающими тестирование, контроль, документирование;
управляющими воздействиями, на показатели качества на всех этапах жизненного цикла программы.
Должны выявлять:
все отклонения от заданных параметров качества объектов и процессов;
отклонения от предписанной технологии тестирования на промежуточных и заключительных этапах разработки.
Должны анализировать возможные последствия выявленных отклонений от требований технического задания или спецификаций ПО. Результатом анализа могут являться либо меры по устранению отклонений либо пересмотр ТЗ или спецификаций, в случае если вариант с их полным выполнением неприемлем по срокам или затратам ресурсов.
Таким образом, основные задачи данной группы специалистов сосредоточены на контроле качества процессов и результатов выполнения работ. Кроме того, на них лежит ответственность за принятие организационных и технологических мер для достижения необходимого качества, обеспечивающего выполнение требований технического задания и спецификаций [33].
Непосредственные разработчики компонентов и программного обеспечения в целом (с заданными показателями качества). В процессе управления качеством задача данной группы состоит в тщательном соблюдении принятой в фирме технологии разработки, тестирования и испытаний и в формировании всех предписанных руководствами исходных и отчетных документов. При этом предполагается, что выбранная технология тестирования способна обеспечить необходимые значения показателей качества, а достижение заданных функциональных характеристик гарантируется тематической квалификацией соответствующих специалистов и регулярным контролем данных характеристик в процессе разработки.
Система стандартизированного документирования частных работ должна обеспечить объективное отражение достигнутого качества компонентов и процессов их создания на всех этапах разработки.
Организационное разделение специалистов, осуществляющих разработку и тестирование ПО, и специалистов, контролирующих и управляющих его качеством в процессе разработки, обеспечивает независимый достоверный контроль качества результатов разработки и эффективное достижение заданных характеристик.
