Слайд 1Управление разработкой информационных систем
Лекционный курс
Слайд 2Главные мысли курса. Что должны понимать?
Что такое ИС. Ее функции,
роль, состав. Нужно четко понимать, что информационная система – инструмент
поддержки бизнес-процессов, один из важнейших активов бизнеса. Что оказание ИТ-услуг – один из бизнес-процессов предприятия, поддерживающий остальные. Нужно представлять типы ИС, функции ИС (ее ценность для бизнеса), состав ИС.
Понимать, что разработка – единый бизнес-процесс, интегрированный через результаты и поддерживаемый комплексом ПО. Состав стадий и операций процесса определяется стандартом ИСО 12207, в РФ – ГОСТ 34.XXX
Процесс разработки выстроен вдоль жизненного цикла главного результата – изменения состояние автоматизируемой системы при помощи автоматизации
Что такое жизненный цикл ИС, для чего он нужен и из чего состоит, знать содержание каждого из этапов ЖЦ, результаты этапов, средства поддержки каждого из этапов
Что основные процессы поддерживается обеспечивающими процессами и управляется управляющими. Необходимо знать наиболее важные обеспечивающие и управляющие процессы, их содержание, результаты, средства поддержки)
Слайд 3Управление требованиями к ИС с помощью языка UML
Лекция 7
Слайд 4Управление требованиями
Целью дисциплины управления требованиями является:
Создание и сопровождение соглашения с
клиентами и прочими заинтересованными лицами о том, что система должна
делать;
Обеспечение понимания разработчиками требований к системе;
Определение границ системы;
Обеспечение основы для планирования работ;
Определение интерфейса пользователя системы
Слайд 5Требования являются основой анализа и проектирования
Слайд 6Главные участники управления требованиями – системный аналитик и постановщик требований
Слайд 7Модель вариантов использования (Use Case model)
Модель вариантов использования представляет собой
модель предполагаемых функций системы и ее окружения, и служит договором
между заказчиком и разработчиками.
Модель вариантов использования используется в качестве важного вклада в деятельность в области анализа, проектирования и тестирования ИС
Модель описывает функциональные требования к ИС в терминах «вариантов использования»
Слайд 8Модель Use Case структурирует прочие классы моделей по функциональным требованиям
Слайд 9Виды требований. Определения.
Слайд 10Модель Use Case и функциональные требования
Для разработки моделей функциональных требований
используется диаграмма вариантов использования (Use Case)
Модель функциональных требований описывает собственно
функциональные требования к системе, внешние по отношению к моделируемой системе субъекты и объекты, взаимодействующие с системой и не являющейся ее частью, и связи между этими субъектами, объектами и функциональными требованиями
Модель функциональных требований к системе должна строиться как иерархия диаграмм
Слайд 11Пример архитектуры модели требований
Слайд 12Примерная структура иерархии модели
Первый уровень иерархии может включать следующие компоненты:
пакет
Последующие
уровни:
пакет или функциональные требования,
субъектов и объектов, взаимодействующих с системой и
не являющейся ее частью,
связи между элементами диаграммы
Слайд 13Изображение пакета
На изображении пакета указывается наименование.
Наименование производится исходя
из сути содержимого пакета
Слайд 14Изображение функционального требования
Рекомендуется именовать функции с использованием отглагольных существительных, например,
«определение состояния счета», «регистрация на курс»
Слайд 15Изображение участника (актора)
Актором на диаграммах Use Case является субъект или
объект, взаимодействующий с системой.
Актор определяет согласованный набор ролей, которые
пользователи системы могут играть при взаимодействии с ним. Например, роль актора может играть физическая или внешняя система.
Актор ответственнен, например, за ввод информации в систему, получение информации из системы и т.п.
Слайд 16Один и тот же человек может играть различную роль при
работе с ИС
Слайд 17Связи в модели функций имеют место:
Между пакетами;
Между ролью и функциональным
требованием;
Между функциями;
Между ролями.
Слайд 18Зависимости между пакетами требований
Между пакетами может существовать связь зависимости.
Связь обозначается
прерывистой линией со стрелкой.
Связь должна проводится от зависимого пакета
к независимому
Слайд 19Зависимости между требованиями и акторами
Между актором и функциональным требованием устанавливается
связь, которая называется ассоциацией.
Связь показывает взаимодействие между актором и
функцией.
Связь может быть двунаправленной.
Связь обозначается сплошной линией со стрелкой или без нее
Слайд 20Между функциями могут быть установлены связи
Связь зависимости со стереотипом «include»
означает, что независимая функция обязательно выполняется каждый раз, когда выполняется
зависимая
Слайд 21Между функциями могут быть установлены связи
Связь зависимости со стереотипом «extend»
означает, что независимая функция обязательно выполняется каждый раз, когда выполняется
зависимая
Слайд 24Варианты использования и модели реализации
Модель реализации требования связывается с символом
варианта использования
Слайд 25Диаграмма вариантов использования
Пример для банковской системы
