Содержание
- 2. Домашнее задание Поправить модели в Archi по замечаниям Определить логическую модель данных: выделить сущности (бизнес-объекты) определить
- 3. Что было на прошлой лекции
- 4. О чем будем говорить
- 5. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ
- 6. Что такое требования Документ или его раздел, документально фиксирующий и уточняющий потребности. Требование может быть приложением
- 7. ТРЕБОВАНИЯ В SWEBOK SOFTWARE ENGINEERING BODY OF KNOWLEDGE
- 8. Требования к ПО Software Requirements Требования - свойства программного обеспечения, которые должны быть надлежащим образом представлены
- 9. Область знаний “Программные требования”
- 10. Разграничение требований к продукту и процессу Например: Требование к процессу функционирования ПО - работа в режиме
- 11. Откуда берутся программные системы Разработка под заказ Поиск заказчика Договорные отношения Сбор требований Прототип Проектирование Конструирование
- 12. Откуда берутся требования От заинтересованных лиц – (stakeholders) Заинтересованное лицо – некто, имеющий возможность (в том
- 13. Извлечение требований
- 14. Определение программной инженерии Дисциплина программной инженерии отвечает за то, чтобы требования заказчика были удовлетворены
- 15. Функциональные и нефункциональные требования функциональные требования задают “что” система должна делать часто функциональные требования представляют в
- 16. Use case Сценарий использования, вариант использования, прецедент использования (англ. use case) — в разработке программного обеспечения
- 17. Примеры Use case
- 18. Потребности заинтересованных сторон Потребности – отражают проблемы бизнеса, персоны или процесса, которые должны быть соотнесены с
- 19. Виды требований Группа функциональных требований - определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками
- 20. Бизнес-правила Группа нефункциональных требований (Non-Functional Requirements) Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами,
- 21. Примеры бизнес-правил
- 23. Feature feature - “множество логически связанных функциональных требований, которые предоставляют определенные возможности для пользователя и удовлетворяют
- 24. Feature Features: «тот самый список характеристик, указанный на коробке продукта» в случае создания «коробочного ПО» список
- 26. Внешние интерфейсы Внешние интерфейсы – часто подменяются “пользовательским интерфейсом”. Вопросы организации пользовательского интерфейса безусловно важны в
- 27. Качество и ограничения Атрибуты качества – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей
- 28. Системные требования Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не
- 29. Независимые или общие свойства требования, которые адресованы к системе в целом, и не могут быть соотнесены
- 30. Требования с количественной оценкой требования, поддающиеся количественному определению/измерению например, система должна обеспечить пропускную способность “столько-то запросов
- 31. Требования с количественной оценкой требование “система должна вести журнал подключений пользователей” может и должно детализироваться с
- 32. Требования с количественной оценкой требование с формулировкой “система должна обладать интуитивно-понятным пользовательским интерфейсом” – непроверяемо его
- 33. Большинство требований с количественной оценкой относится к атрибутам качества реальное требование реального проекта по электронному документообороту:
- 34. Системные требования и программные требования комбинация взаимодействующих элементов для достижения определенных целей может включать аппаратные средства,
- 35. Свойства процесса определения требований процесс работы с требованиями инициируется в начале проекта и продолжается на протяжении
- 36. Участники процесса управления требованиями заинтересованные лица – (software) stakeholders) заинтересованное лицо – некто, имеющий возможность (в
- 37. Типичные примеры ролей стейкхолдеров Пользователи (Users): группа, охватывающая тех людей, кто будет непосредственно использовать программное обеспечение;
- 38. Типичные примеры ролей Аналитики играют роль “представителей” потребителей; Регуляторы: многие области применения (“домены”) являются регулируемыми, например,
- 39. Типичные примеры ролей Инженеры по программному обеспечению (архитекторы), инженеры-программисты (Software Enginner): лица, обладающие обоснованным интересом к
- 40. Качество и улучшение процессов Удовлетворение потребностей заказчика является целью любого программного проекта. Соответственно, обеспечение адекватности реализации
- 41. Качество и улучшение процессов Реальная отечественная практика многих организаций, занимающихся разработкой ПО, показывает, что очень немногие
- 42. Основные принципы обеспечения качества и улучшение процессов Покрытие процессов работы с требованиями с точки зрения стандартов
- 43. Классификация требований Функциональные и нефункциональные требования Внутренние (с другими требованиями) или внешние зависимости Требования к процессу
- 44. Классификация требований Карла Вигерса
- 45. Источники требований Необходимо идентифицировать все возможные источники требований, значимые для решения задач проекта Определение целей Знание
- 46. Извлечение требований Идентификация заинтересованных лиц, их взаимодействия, выполняемых ими бизнес-процессов Обеспечение взаимодействия между пользователями и аналитиками
- 48. Прототипирование В общем случае, прототипирование подразумевает проверку инженерной интерпретации программных требований и извлечение новых требований, неопределенных
- 49. Техники извлечения требований “Разъясняющие встречи” - в оригинале звучит как “facilitated meetings”; достаточно емкий по смыслу
- 50. Техники извлечения требований Наблюдение (observation) – подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в
- 51. Вокшопы, ролевые игры, социодрама
- 52. Требования к метаданным Определение требований к метаданным начинается с содержательной части. Необходимо выяснить, что именно должны
- 53. Категории вопросов к стейкхолдерам Изменения. Как часто будут пересматриваться и обновляться наборы и атрибуты метаданных? Синхронизация.
- 54. Пример метамодели (модели репозитория метаданных)
- 55. ТЕХНИЧЕСКОЕ ЗАДАНИЕ
- 56. Техническое задание Служит основой договора на разработку ИС (является приложением к нему) Определяет ПМИ (программу и
- 57. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы ТЗ на АС является основным документом, определяющим требования
- 58. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы Требования к АС в объеме, установленном настоящим стандартом,
- 59. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы В ТЗ на АС включают только те требования,
- 60. СОСТАВ И СОДЕРЖАНИЕ ТЗ 1) общие сведения; 2) назначение и цели создания (развития) системы; 3) характеристика
- 61. Общие сведения 1) полное наименование системы и ее условное обозначение; 2) шифр темы или шифр (номер)
- 62. Назначение и цели создания (развития) системы 1) назначение системы вид автоматизируемой деятельности (управление, проектирование и т.
- 63. Требования к системе требования к системе в целом; 2) требования к функциям (задачам), выполняемым системой; 3)
- 64. Требования к системе требования к системе в целом; требования к структуре и функционированию системы; требования к
- 65. Требования к структуре и функционированию системы 1) перечень подсистем, их назначение и основные характеристики, требования к
- 66. Требования к численности и квалификации персонала на АС требования к численности персонала (пользователей) АС; требования к
- 67. Требования к показателям назначения АС Значения параметров, характеризующие степень соответствия системы ее назначению. Для АСУ указывают:
- 68. Требования к надежности 1) состав и количественные значения показателей надежности для системы в целом или ее
- 69. Требования по безопасности Требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств
- 70. Требования по эргономике и технической эстетике Показатели АС, задающие необходимое качество взаимодействия человека с машиной и
- 71. Требования к транспортабельности Для подвижных АС включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также
- 72. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению 1) условия и регламент (режим) эксплуатации, которые должны
- 73. Требования к защите информации от несанкционированного доступа Требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.
- 74. Требованиях по сохранности информации Перечень событий: аварий, отказов технических средств (в том числе - потеря питания)
- 75. Требования к средствам защиты от внешних воздействий 1) требования к радиоэлектронной защите средств АС; 2) требования
- 76. Требования по патентной чистоте Перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и
- 77. Требования к стандартизации и унификации Показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач)
- 78. Дополнительные требования 1) требования к оснащению системы устройствами для обучения персонала (тренажерами, другими устройствами аналогичного назначения)
- 79. Требования к системе 2) требования к функциям (задачам), выполняемым системой 1) по каждой подсистеме перечень функций,
- 80. Требования к системе 3) требования к видам обеспечения: требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому,
- 81. Требования к математическому обеспечению Требования к составу, области применения (ограничения) и способам, использования в системе математических
- 82. Требования к информационному обеспечению 1) к составу, структуре и способам организации данных в системе; 2) к
- 83. Требования к лингвистическому обеспечению Для лингвистического обеспечения системы приводят требования к применению в системе языков программирования
- 84. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования: 1) к независимости программных
- 85. Для технического обеспечения системы приводят требования 1) к видам технических средств, в том числе к видам
- 86. В требованиях к метрологическому обеспечению приводят: 1) предварительный перечень измерительных каналов; 2) требования к точности измерений
- 87. Для организационного обеспечения приводят требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих
- 88. Для методического обеспечения Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых
- 89. Состав и содержание работ по созданию (развитию) системы должен содержать перечень стадий и этапов работ по
- 90. Порядок контроля и приемки системы 1) виды, состав, объем и методы испытаний системы и ее составных
- 91. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие Необходимо
- 92. Требования к документированию 1) согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов,
- 93. Источники разработки Должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах,
- 94. В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие 1) расчет ожидаемой эффективности
- 95. ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС 1. Проект ТЗ на АС разрабатывает организация-разработчик системы
- 96. ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС 5. Если при согласовании проекта ТЗ на АС
- 97. ТРЕБОВАНИЯ В ВОДОПАДЕ И ГИБКИХ МЕТОДОЛОНЯХ
- 98. Предпроектная проработка Инициирование Подготовка Реализация Закрытие проекта ЗнА – запрос на автоматизацию ФТТ – функционально-технические требования
- 100. Водопад, каскадная модель
- 101. Особенности водопада 1 Четкий регламент управления проектом Разработка проходит в соответствии с четким планом Стоимость и
- 102. Особенности водопада 2 Продукты, разработанные по данной модели могут иметь недочеты (список требований нельзя скорректировать в
- 103. Когда использовать водопад? Только тогда, когда требования известны, понятны и зафиксированы, и противоречивых требований не имеется.
- 105. Agile (гибкая методология разработки)
- 106. Требования составляют бэклог продукта это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди
- 107. Бэклог спринта
- 108. Сравнение моделей разработки ПО
- 109. Сравнение моделей разработки ПО
- 110. Сравнение моделей разработки ПО
- 114. ARCHIMATE
- 115. Понятие сервиса Сервис – это единица функциональности, которую система предоставляет своему окружению, скрывая при этом внутренние
- 116. Понятие интерфейса Интерфейс – это точка доступа, в которой сервис становится доступным внешнему окружению.
- 120. Страхование
- 124. Оплата покупки
- 125. Управление инцидентами
- 126. Домашнее задание Поправить модели в Archi по замечаниям Сформировать требования к своим приложениям в форме ТЗ
- 128. Скачать презентацию