- •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.5 Измерения
Численные измерения, используются в процессе управления требованиями для оценок состояния требований и контроля выполнения работ, связанных с управлением требованиями и их реализацией. Работа по выбору метрик и измерениям координирует ГТР. На основе статистической обработки накапливаемой в процессе выполнения проектов информации ГТР обеспечивает новые проекты все более точными рекомендациями по планированию, оптимизации рисков, выбору технологий.
Использование измерений и выбор метрик в проекте осуществляет Аналитик. Рекомендуются измерения требований по важности, статусу, степени выполнения, трудоемкости.
8.5.1 Показатель важности
Для требований вводится и отслеживается показатель важности требований, шкала показателя важности вводится при разработке требований Аналитиком и поддерживается на протяжении всего проекта. Минимально рекомендуемая шкала важности включает следующие значения: «обязательное», «рекомендованное», «опциональное».
8.5.2 Стабильность
Стабильность требований отражает планируемую степень их неизменности в процессе проекта. Для задания этого параметра используется количество плановых коррекций требования в процессе проекта.
8.5.3 Статус требований
Статус требования указывает текущее состояние требования. Информация о статусе требований важна для членов рабочей группы для эффективной организации работ. Рекомендованные значения статуса требования («получен запрос на изменение», «утверждено», «встроено в проект»).
8.5.4 Степень выполнения требований
Степень выполнения требований указывает этап, на котором находятся работы по реализации требований, например: «проектирование», «кодирование», «отладка», «тестирование», - или процент выполненных работ по реализации требований.
8.5.5 Трудоемкость
Трудоемкость выполнения требования указывает количество человеко-дней, потребовавшихся для его реализации.
8.6 Верификация
Верификация процессов управления требованиями выполняется на нескольких уровнях для обеспечения гарантии исполнения всех необходимых действий по управлению требованиями.
8.6.1 Контроль со стороны руководства
Руководство на периодической основе – один раз в месяц, проводит проверку выполнения процедур и правил выполнения управления требованиями. Проверке подлежит:
Наличие актуальной версии утвержденного ТЗ в проектах.
Наличие отчетов по анализу ТЗ.
Наличие решений по проблемам внутри проекта и сформированного плана управления рисками.
Своевременность выноса на уровень руководства проблем и рисков, которые не могут быть решены внутри проекта.
Отчеты ГОК по проверке процессов управления требований в проектах.
8.6.2 Контроль со стороны руководителя проекта
Менеджер проекта на периодической основе – один раз в неделю, и по мере возникновения необходимости изменения требований проводит проверки связанные с управлением требованиями.
Проверке подлежат:
Корректность требований.
Наличие необходимых документов по управлению требованиями. Выполнение необходимых процедур по их согласованию и утверждению.
Состав и статус решаемых с заказчиком вопросов по управлению требованиями
Контроль завершенности встраивания измененных требований в проект.
Доступность материалов по управлению требованиями для членов рабочей группы
Выполнение решений принятых по рискам и проблемам.
