Технологии проектирования информационных систем. Структурные модели предметной области презентация
Содержание
- 2. Требования к моделям предметной области Формализованность, обеспечивающая однозначное описание структуры предметной
- 3. Структурный аспект моделирования предметной области Объектная структура отражает состав взаимодействующих в
- 4. Оценочный аспект моделирования предметной области Оценочный аспект моделирования предметной области связан
- 5. Уровни проектирования Внешний уровень проектирования – этап выяснения взаимодействия системы с
- 6. Модель объектной структуры Объектная структура отражает состав взаимодействующих в процессах материальных
- 7. Модель функциональной структуры Функциональная структура отражает взаимосвязь функций по преобразованию объектов
- 8. Модель структуры управления Модель структуры управления отражает события и бизнес-правила, которые
- 9. Модель организационной структуры Организационная структура отражает взаимодействие организационных единиц предприятия при
- 10. Модель технической структуры Техническая структура отражает топологию расположения и способы коммуникации
- 11. Взаимосвязь областей проектирования и структурных моделей предметной области
- 12. Понятие требования Требования – это исходные данные, на основа-нии которых проектируются
- 13. Источники требований Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения) Нормативное
- 14. Заинтересованные лица
- 15. Использование требований при разработке ИС
- 16. Методы сбора требований Интервью Анкетирование Наблюдение Самостоятельное описание требований Совместные семинары
- 17. Интервью Подготовка – планирование процесса опроса и выработка стратегии управления этим
- 18. Интервью Подготовка – планирование процесса опроса и выработка стратегии управления этим
- 19. Анкетирование Преимущество: наименее затратный способ извлечения информации. Недостаток: наименее эффективный способ
- 20. Наблюдение Применяется для непосредственного сбора сведений о параметрах, признаках и объектах
- 21. Самостоятельное описание требований Используется при наличии: хорошо структурированной документации, описывающей устоявшиеся
- 22. Совместные семинары Групповое обсуждение по методу «мозгового штурма» проводится с
- 23. Прототипирование Прототипирование является ключевым компонентом технологии быстрой разработки приложений (RAD –
- 24. Классификация требований
- 25. Уровни требований
- 27. Бизнес- требования Назначение: Формулировка цели проектирования ИС Где описываются:
- 28. Требования пользователей Назначение: определяют набор пользовательских задач, которые должна решать
- 29. Функциональные системные требования Назначение: определяют способы реализации ИС. Где
- 30. Нефункциональные требования – это требования к характеру поведения системы Нефункциональные
- 31. Диаграмма требований
- 32. Особенности нефункциональных требований Заказчики часто забывают про эти требования и не
- 33. Категории нефункциональных требований Основные: Удобство использования Надежность Производительность Эксплуатационная пригодность
- 34. Требование «Удобство использования»
- 35. Требование «Надежность»
- 36. Требование «Производительность»
- 37. Требование «Эксплуатационная пригодность» Тестируемость Приспособляемость Совместимость Способность к обновлению Расширяемость
- 38. Заполнить таблицу
- 39. Строжайшее и единственное правило построения систем программного обеспечения - решить точно,
- 40. Свойства требований Полнота Ясность (простота, точность, недвусмысленность) Верифицируемость (тестируемость) Необходимость
- 41. Полнота требования означает, что текст требования не требует дополнительной детализации, то
- 42. Ясность – недвусмысленность, определенность, однозначность спецификаций. Ясность – недвусмысленность, определенность,
- 43. Требование 1 (неясное): Требование 1 (неясное): Система не должна
- 44. Требование 2 (неясное): Требование 2 (неясное): Иногда пользователь будет
- 45. Верифицируемость – пригодность к проверке. Тестировщики должны иметь возможность проверить, было
- 46. Необходимым считается требование, невыполнение которого угрожает работоспособности или эффективности ИС.
- 47. Осуществимость (выполнимость) Осуществимость (выполнимость) Требование должно быть выполнимо в рамках существующих
- 48. Выполнимо ли требование заказчика: «Реализовать новую функциональность ИС в процессе проведения
- 49. Требование считается элементарным, если оно содержит только один трассируемый элемент, который
- 50. Требование является независимым, если для его понимания не нужно знать другие
- 51. Корректность – согласованность, непротиворечивость. Требования не должны противоречить требованиям своего уровня
- 52. Прямые конфликты возникают, когда ожидается различное поведение системы в одной и
- 53. Каких требований не должно быть Спецификация требований не должна содержать
- 54. Скачать презентацию
Слайды и текст этой презентации
Скачать презентацию на тему Технологии проектирования информационных систем. Структурные модели предметной области можно ниже: