Презентация Начальная фаза проекта создания (модернизации) ИС в RUP, формирование и анализ требований онлайн

Содержание слайда: Начальная фаза проекта создания (модернизации) ИС в RUP, формирование и анализ требований д.э.н., проф. Тельнов Ю.Ф.

Содержание слайда: Вопросы Цели (задачи) начальной фазы проекта Роль аналитика на начальной фазе формирования требований Моделирование вариантов (прецедентов) использования –функциональных требований в RSA

Содержание слайда: 1. Цели (задачи) начальной фазы жизненного цикла (Inception) Понять, что создавать - определить общее описание или границы (рамки) проекта, установить концепцию, цели и требования, назначение (для кого) Определить ключевые функции системы – определить варианты (прецеденты) использования Выявить хотя бы одно возможное архитектурное решение (одну возможную архитектуру), добиться соглашения между заинтересованными сторонами для дальнейшего продвижения Оценить стоимость, сроки и риски, связанные с проектом - разработать экономическое обоснование, минимизировать риски Настройка процесса разработки (настройка RUP)- решить какому процессу следовать и какие средства использовать Веха целей жизненного цикла (LCO – Lifecycle Objective)

Содержание слайда: Диаграмма вариантов (прецедентов) использования

Содержание слайда: Приблизительный перечень артефактов начальной фазы (Крэг Ларман)

Содержание слайда: 1. Определить общее описание (границы) проекта Согласовать высокоуровневую концепцию: Возможности и преимущества приложения (системы) Решаемые проблемы Конечные пользователи Перечень функций высокого уровня (обзор ключевых прецедентов) Наиболее существенные нефункциональные требования (ОС, СУБД, надежность, масштабируемость, качество, лицензирование) Сформировать широкое, но не глубокое описание системы Определение и краткое описание акторов (пользователей и внешних систем и их информационных потребностей) Определение и краткое описание вариантов использования (типичные случаи использования системы, совокупность типичных взаимодействий составляет прецедент использования – Use-Case) Выделение наиболее критичных прецедентов использования (10-20%) – более детальное описание, остальные – один, два абзаца Подробное описание ключевых акторов и вариантов использования Описание прецедентов использования (детальное описание основного потока и выделение альтернативных потоков событий) – 10-20 % Прототипы пользовательского интерфейса

Содержание слайда: 2. Определить ключевые функции системы по критериям: Функциональность является ключевой для приложения или использует ключевые интерфейсы (анализ рисков, производительности, безопасности системы) – определяет архитектор приложения и менеджер Функциональность обязательно должна быть реализована, компонент, без которого не будет работать приложение – определяет архитектор приложения и менеджер Функциональность, некритичная с позиции менеджмента проектом – определяет менеджер проекта Выбор прецедентов А) Из 15 – 4 – для малой системы В) Из 40 – 9 – для большой системы С) При модернизации – 1 из имеющихся, 2 из 9

Содержание слайда: 3. Архитектурное решение Принятие решения о возможности реализации системы на основе обоснования проектных решений в рамках хотя бы одной архитектуры. Вопросы при выборе архитектурных решений: Наличие сходных систем. Какие технологии и архитектуры применяются в них? Анализ существующей архитектуры, обоснование необходимости ее развития Обоснование выбора новых технологий по затратам и рискам Обоснование выбора программных компонентов (СУБД, ПО промежуточного слоя,…) по затратам и рискам А) 1 функциональный прецедент В) 2 функциональный прецедента С) 2 функциональных прецедента Демонстрация макетов заказчикам

Содержание слайда: 4. Оценка стоимости, сроков и рисков проекта Экономическое обоснование проекта – основание для адекватного финансирования проекта (совокупная стоимость владения, ROI, риски) 5. Настройка процесса разработки (настройка RUP) - решить какому процессу следовать и какие средства использовать

Содержание слайда: Рецензирование проекта. Веха целей жизненного цикла – оценка: Согласие заинтересованных сторон по вопросу определения границ проекта и первоначальной его стоимости/сроков Согласие по набору требований и существует общая точка зрения на эти требования Согласие в оценке стоимости/сроков, приоритетах, рисках и процессе разработки и стратегии борьбы с рисками приемлемы

Содержание слайда: 2. Роли участников проекта создания (модернизации ИС)

Содержание слайда: Роль аналитика на начальной фазе формирования требований Понимание потребностей пользователей и других заинтересованных лиц Документирование и ранжирование требований Согласование требований со всеми заинтересованными лицами: пользователями, архитекторами, разработчиками, менеджерами проектов

Содержание слайда: Требования к системному аналитику Уметь взаимодействовать с заинтересованными лицами Хорошо понимать область проблемы и быть способным быстро приобретать знания Способность ясно и четко излагать свои мысли как письменно, так и устно Способность моделировать бизнес-процессы и формулировать требования Понимать место работы аналитика в жизненном цикле ИС

Содержание слайда: От требований к архитектуре

Содержание слайда: Список активностей (задач) системного аналитика Понимание бизнес-процессов – моделирование бизнес-процессов Определение потребностей заинтересованных лиц – работа в рабочих группах (очередность задачи, важнейшие нефункциональные требования) Создание концепции Список заинтересованных лиц Ограничения: бюджет, технологии, ОС-ы, совместимость с другими системами Формулировка проблемы Список свойств системы

Содержание слайда: Формулировка проблемы Описание проблемы Затрагивает <заинтересованные лица>, например, заказчики Проблема приводит к <недостатки> Успешное решение проблемы <выгоды>

Содержание слайда: Свойство, характеристика разрабатываемого продукта Описание Значимость Стоимость Приоритет разработки

Содержание слайда: Разработка модели прецедентов и глоссария – функциональных требований Выявить акторов – проанализируйте свойства и запросы заинтересованных лиц. Описания – одна фраза на актор. Выявить прецеденты (варианты) использования – взаимодействия акторов с системой и их группировка (активности/функции в бизнес-процессах) Определение взаимодействия прецедента с другими пользователями или системами (акторами) Описание акторов (по абзацу) и прецедентов (по нескольким абзацам). Может потребовать пересмотр состава прецедентов Создание глоссария (объектная терминология) Проверка глоссария – все ли объекты используются в прецедентах Выявление критичных прецедентов использования (20% от общего числа) Для наиболее критичных прецедентов подробное сценарное описание На стадии проектирования – подробное описание всех остальных прецедентов использования и составление глоссария Дополнительные связи наследования между акторами и включения, расширения и обобщения для прецедентов

Содержание слайда: Фиксация нефункциональных требований Атрибуты качества (удобство, надежность, производительность, поддержка и др.) Юридические и инструктивные требования и стандарты Прочие требования, требования к ОС, окружению, совместимости, протоколам и др.

Содержание слайда: Разработка прототипов пользовательского интерфейса Концептуальный прототип – визуализация и демонстрация ключевых возможностей, не связанных с конкретными прецедентами использования Прототипы прецедентов использования или раскадровки прецедентов использования (основные экраны, иллюстрирующие функциональность) - скриншоты

Содержание слайда: Обновление и уточнение требований Оценка рисков, сроков, стоимости Система управления изменениями совместно с менеджером проекта и группой управления изменениями Обеспечить выпуск и тестирование требований – программы, документация, учебные материалы

Содержание слайда: 3. Моделирование прецедентов (вариантов) использования – функциональных требований в RSA

Содержание слайда: Диаграмма деятельности (activity – активностей) Диаграммы деятельности – это технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ. Во многих случаях DA напоминают блок-схемы, но принципиальная разница заключается в том, что они поддерживают параллельное процессы.

Содержание слайда: Типы элементов Действие – action Управляющий поток – control flow Принятие решений – Decision (Хor) Разделение потока - Fork (And) Объединение потоков – Join (And) Слияние потоков – Merge (Or) Начальная и конечная точка (Initial, End) Разбиение деятельности (Partition)

Содержание слайда: Пример диаграммы деятельностей

Содержание слайда: Пример диаграммы активностей

Содержание слайда: Бизнес-процесс – границы системы

Содержание слайда: Модель прецедентов (вариантов) использования

Содержание слайда: Роль модели прецедентов (вариантов) использования

Содержание слайда: Диаграмма вариантов использования

Содержание слайда: Характеристики акторов Актор (исполнитель роли) – это сущность, обладающая поведением (человек, подразделение, внешняя компьютерная система) Основной актор – его задачи связаны с использованием системы (прецедента), инициирует работу системы, задачи определяют названия прецедентов Вспомогательный актор – обслуживает систему, выполняет сервисные функции, воспринимает запросы от прецедента (варианта) использования, предоставляет информацию

Содержание слайда: Описание актора

Содержание слайда: Поиск акторов

Содержание слайда: Вариант (прецедент) использования – USE-CASE

Содержание слайда: Поиск вариантов использования

Содержание слайда: Отображение бизнес-модели в модель ПО

Содержание слайда: Диаграмма вариантов (прецедентов) использования

Содержание слайда: Дополнительные элементы модели вариантов использования

Содержание слайда: Дополнительные элементы модели вариантов использования

Содержание слайда: Структура диалога актора и системы

Содержание слайда: Понятие потока событий

Содержание слайда: Пример потоков событий

Содержание слайда: Проект интерфейса пользователя

Содержание слайда: Предусловия и постусловия

Содержание слайда: Шаблон полного описания прецедента

Содержание слайда: Шаблон полного описания прецедента

Содержание слайда: Декомпозиция функциональных требований (бизнес-функций) на функции компьютерной обработки данных в сценарии прецедента

Содержание слайда: Декомпозиция функциональных требований (бизнес-функций) на функции компьютерной обработки данных