Содержание
- 2. Спецификация требований особый итоговый набор расположенных по приоритетам требований, который является формальным соглашением заказчика с разработчиком
- 3. Спецификация требований требования: должна быть простой, ясной и понятной пользователю неспециалисту должна быть точной, подробной, формальной
- 4. Спецификация требований Пользовательские требования Системные требования
- 5. Спецификация требований (основные разделы) Введение Общее описание Функции системы Внешний интерфейс Нефункциональные требования
- 6. Введение обзор спецификации, позволяющий разобраться в структуре и принципах ее построения. определяется специфицируемая далее система или
- 7. Общее описание Продукт - особенности продукта или его основные функции, основные группы требований и их взаимосвязь
- 8. Функции системы · название и приоритет; · системные входные и выходные данные, или последовательности «воздействие –
- 9. Внешний интерфейс ссылки на стандарты графического интерфейса, шрифтов, элементов управления и т.п.; конфигурация экрана, стандартные кнопки
- 10. Нефункциональные требования требования к производительности, атрибуты качества продукта, требования к безопасности, охране труда и т.д. словарь
- 11. Рекомендации по документированию требований
- 12. Пользовательские требования 1.Если требование независимое и простое, то оно может быть записано в виде нескольких простых
- 13. Системные требования 1.Перед написанием спецификации системных требований необходимо выбрать стиль описания. 2.Для каждого требования: ·определить требование
- 14. Требование должно быть понятным Требование должно быть конкретным Требование должно быть тестируемым
- 15. Стандарты на документирование требований
- 16. IEEE 830-1993 (спецификация ФТ) Введение цели документа назначение программного продукта определения, термины, сокращения список литературы обзор
- 17. Способы структурирования требований 1.По основным свойствам. Предоставляемые программой сервисы определяются с помощью пар «стимул – реакция».
- 18. 5.По иерархии функций. Это традиционный способ упорядочивания детальных требований. Программа разбивается на множество высокоуровневых функций, каждая
- 19. ГОСТ 34.602-89 (Техническое задание) Общие сведения назначение и цели создания (развития) системы; характеристика объектов автоматизации; требования
- 20. Шаблон SRS, предложенный в RUP 1. Введение. 1.1. Цель. 1.2. Краткая сводка возможностей. 1.3. Определения, акронимы
- 21. 2.2. Предположения и зависимости. Данная секция описывает ключевые технические возможности, компоненты, подсистемы, связанные проекты, которые могут
- 22. 3. Описание требований 3.1. Описание вариантов использования. Параграф содержит описание вариантов использования и связанных с ними
- 23. MSF (Microsoft Solution Framework) Бизнес-преимущества описание преимуществ формулировка видения анализ выгод Концепция решения цели, задачи, предложения
- 24. MSF (Microsoft Solution Framework) 3. Рамки список характеристик/функций вне рамок стратегия подготовки релизов критерии применимости эксплуатационные
- 25. Оценка качества спецификации требований
- 26. Характеристики качества · полнота, согласованность, · способность к модификации · трассируемость.
- 27. Аттестация требований экспертиза спецификации, неофициальная (во время разработки) официальная (по окончании разработки) прототипирование, автоматизированный анализ тестирование
- 28. Проблемы большой объем документации большая команда экспертов
- 29. Управление
- 30. Принципы управления требованиями 1.Определение основной (базовой) версии спецификации требований для конкретной версии продукта; 2.Анализ предлагаемых изменений
- 31. Процесс управления требованиями определить: · методы и средства управления версиями спецификации и отдельных требований; · процесс
- 32. Статус требования В процессе выполнения проекта требование, обычно, изменяет свое состояние от начального («предложено»), до конечного,
- 35. Управление изменениями Описание процесса контроля изменений должно содержать: 1.Границы применения процесса. Должны быть перечислены те продукты
- 36. Управление связями требований Трассируемость требований позволяет решить следующие задачи. 1.Продемонстрировать, что все требования проекта реализованы. 2.Снизить
- 37. Матрица трассирования
- 38. Уровни зрелости процесса управления требованиями
- 39. В зрелой организации: · имеются четко определенные процедуры создания программного продукта и управления программными проектами; ·
- 40. Модель зрелости способностей предприятий в области разработки программного обеспечения (Capability Maturity Model for Software – CMM)
- 41. В модели CMM различают пять уровней зрелости (наивысшим из которых является пятый) и насчитывается 24 ключевые
- 42. Capability Maturity Model – система качества, разработанная SEI (Software Engineering Institute) Цель СММ: гарантирование реализации проекта
- 43. Уровни зрелости процесса управления требованиями Уровень 0. Начальный (Initial) Отсутствие требований На начальном уровне процесс разработки
- 44. Ключевые области На втором уровне определены: 1.Управление требованиями (Requirements Management) – обеспечение возможности установления единого с
- 45. Уровень 3. Определенный (Defined) Организация требований Для третьего уровня зрелости процесса характерно, что все виды деятельности,
- 46. Ключевые области Третий уровень характеризуется включением ключевой области: Разработка требований (Requirements Development)» – разработка и анализ
- 47. Уровень 3. Структурирование требований на третьем уровне зрелости выполняются активности по планированию процесса управления требованиями и
- 48. Ключевые области Использование CASE - СРЕДСТВ - На данном уровне зрелости может возникнуть необходимость применения специализированных
- 49. Уровень 4. Трассировка требований Достижения предыдущих трех уровней зрелости приведет проектную команду к тому, что можно
- 50. Ключевые области Анализ влияния заключается в прослеживании воздействия изменений одного требования на изменение других требований. Анализ
- 51. Уровень 5. Интеграция требований Для создания программного обеспечения, соответствующее требованиям заказчика необходимо, чтобы команда проекта использовала
- 52. Типовые инструменты · моделирование требований; · трассировка требований; · управление версиями.
- 53. СММ
- 54. Первый уровень. ПРПО фирмы никак не организованы, и реальные попытки их улучшения не предпринимаются.
- 55. Второй уровень. Компания на основе анализа успешных проектов начинает повторно использовать подходящие ПРПО. Положительная практика документируется,
- 56. Однако, успех проектов по-прежнему зависит от ведущих специалистов, а ПРПО разработаны только для конкретных областей (бухгалтерское
- 57. Третий уровень . Компания детально стандартизует используемые ПРПО (пока для решения достаточно общих задач) с учетом
- 58. Этот уровень характеризуется тем, что в фирме должна быть создана специальная группа софт-инжиниринга (software engineering process
- 59. Четвертый уровень Все ПРПО компании могут быть использованы для работы над программными проектами разной тематики. Процессы
- 60. Фирма создает базу данных по используемым ПРПО и постоянно ее анализирует. От подобного формализованного опыта существенно
- 62. Скачать презентацию