Управление разработкой информационных систем Лекционный курс Главные мысли курса. Что должны понимать
 Скачать 0.61 Mb.
|
Управление разработкой информационных системЛекционный курсГлавные мысли курса. Что должны понимать?Что такое ИС. Ее функции, роль, состав. Нужно четко понимать, что информационная система – инструмент поддержки бизнес-процессов, один из важнейших активов бизнеса. Что оказание ИТ-услуг – один из бизнес-процессов предприятия, поддерживающий остальные. Нужно представлять типы ИС, функции ИС (ее ценность для бизнеса), состав ИС. Понимать, что разработка – единый бизнес-процесс, интегрированный через результаты и поддерживаемый комплексом ПО. Состав стадий и операций процесса определяется стандартом ИСО 12207, в РФ – ГОСТ 34.XXX Процесс разработки выстроен вдоль жизненного цикла главного результата – изменения состояние автоматизируемой системы при помощи автоматизации Что такое жизненный цикл ИС, для чего он нужен и из чего состоит, знать содержание каждого из этапов ЖЦ, результаты этапов, средства поддержки каждого из этапов Что основные процессы поддерживается обеспечивающими процессами и управляется управляющими. Необходимо знать наиболее важные обеспечивающие и управляющие процессы, их содержание, результаты, средства поддержки) Управление требованиями к ИС с помощью языка UMLЛекция 7Управление требованиямиЦелью дисциплины управления требованиями является:
Обеспечение понимания разработчиками требований к системе; Определение границ системы; Обеспечение основы для планирования работ; Определение интерфейса пользователя системы Требования являются основой анализа и проектированияГлавные участники управления требованиями – системный аналитик и постановщик требованийМодель вариантов использования (Use Case model)Модель вариантов использования представляет собой модель предполагаемых функций системы и ее окружения, и служит договором между заказчиком и разработчиками. Модель вариантов использования используется в качестве важного вклада в деятельность в области анализа, проектирования и тестирования ИС Модель описывает функциональные требования к ИС в терминах «вариантов использования» Модель Use Case структурирует прочие классы моделей по функциональным требованиямВиды требований. Определения.
Модель Use Case и функциональные требованияДля разработки моделей функциональных требований используется диаграмма вариантов использования (Use Case) Модель функциональных требований описывает собственно функциональные требования к системе, внешние по отношению к моделируемой системе субъекты и объекты, взаимодействующие с системой и не являющейся ее частью, и связи между этими субъектами, объектами и функциональными требованиями Модель функциональных требований к системе должна строиться как иерархия диаграмм Пример архитектуры модели требованийПримерная структура иерархии моделиПервый уровень иерархии может включать следующие компоненты:
Последующие уровни: пакет или функциональные требования, субъектов и объектов, взаимодействующих с системой и не являющейся ее частью, связи между элементами диаграммы Изображение пакетаНа изображении пакета указывается наименование. Наименование производится исходя из сути содержимого пакета Изображение функционального требованияРекомендуется именовать функции с использованием отглагольных существительных, например, «определение состояния счета», «регистрация на курс» Изображение участника (актора)Актором на диаграммах Use Case является субъект или объект, взаимодействующий с системой. Актор определяет согласованный набор ролей, которые пользователи системы могут играть при взаимодействии с ним. Например, роль актора может играть физическая или внешняя система. Актор ответственнен, например, за ввод информации в систему, получение информации из системы и т.п. Один и тот же человек может играть различную роль при работе с ИССвязи в модели функций имеют место:Между пакетами; Между ролью и функциональным требованием; Между функциями; Между ролями. Зависимости между пакетами требованийМежду пакетами может существовать связь зависимости. Связь обозначается прерывистой линией со стрелкой. Связь должна проводится от зависимого пакета к независимому Зависимости между требованиями и акторамиМежду актором и функциональным требованием устанавливается связь, которая называется ассоциацией. Связь показывает взаимодействие между актором и функцией. Связь может быть двунаправленной. Связь обозначается сплошной линией со стрелкой или без нее Связь зависимости со стереотипом «include» означает, что независимая функция обязательно выполняется каждый раз, когда выполняется зависимая Связь зависимости со стереотипом «extend» означает, что независимая функция обязательно выполняется каждый раз, когда выполняется зависимая Связь агрегации между функциямиСвязь агрегации между акторамиВарианты использования и модели реализацииМодель реализации требования связывается с символом варианта использования Диаграмма вариантов использования Пример для банковской системы |