20. Этапы проектирования ис с применением uml

Концептуальная модель – бизнес процессы – диаграмма бизнес прецедентов.

Логическая: диаграммы классов, последовательности, состояния, прецедентов

Физическая: диаграммы классов, компонентов., развертывания.

Разработка модели бизнес – прецедента

Описание модели с точки зрения ?????

Прецеденты должны удовлетворять критерию:

1. Что надо сделать, а не как

2. Описать действие с точки зрения инициатора (исполнителя)

3. Прецедент должен возвращать действие, прецедент

4. Последовательность действий прецедента должна представлять собой единую неделимую цепочку

Разработка модели бизнес – объекта

Показывает выполнение бизнес – процесса организации. Ее внутренних исполнителей.

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

Разработка концептуальной модели деятельности

Диаграмма классов без атрибутов, название класса, и свойства модели ???

Последний этап процедуры бизнес – моделирования.

Разработка требований к системе

Необходимо определить область действия ИС

Описание системы прецедентов (спецификация прецедентов):

- Заголовок (название, ответственность, дата)

- Краткое описание

- ограничения

- предусловия

- постусловия

- предположение

- основная последовательность действий

- альтернативные последовательности действий и условия их инициализации

- т. расшир. и вкл. прецендента.

Элементы бизнес модели Модель системы прецедентов

Бизнес – прецедент ------------> Подсистема

Внешний исполнитель ------------> Исполнитель

Внутренний исполнитель ------------> Исполнитель или прецедент

Процессы, выполняемые --внутр--> прецеденты

Исполнителем

Диаграмма прецедентов

Диаграмма последовательностей

Диаграмма видов деятельности

Анализ требований и предварительное проектирование системы

Задачи:

1. Определить проект системы. Должна отвечать всем бизнес требованиям.

2. Разработать общий предварительный проект для всех команд разработчиков.

Основной инструмент – диаграмма классов.

Уточненная диаграмма деятельности, выполненная отдельными прецедентами.

Диаграмма классов с атрибутами, функциями, типами.

Результатом проектирования данного этапа является подробное описание состава

Разработка модели БД и приложений

Преобразование иерархии

Проектирование физической реализации системы

На этом этапе проектируются БД и приложения.

Дополнение значениями их размещения на технических ????

Основные понятия:

1. Компонент – самостоятельный физический модуль системы (принтер, сканер)

2. Зависимость

3. Устройство – узел, не обрабатывающий данные

4. Процессор – узел, выполняющий обработку данных

5. Соединение

Диаграмма разверт.

Недостатки UML: -субъективен -не формализован -устарел

21. Модель процессов msf (тут же про опыт ibm)

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral)

Базовые концепции и принципы модели процессов MSF

# Распределение ответственности при фиксации отчетности

# Наделяйте членов команды полномочиями

# Концентрируйтесь на бизнес-приоритетах

# Единое видение проекта

# Проявляйте гибкость — будьте готовы к переменам

# Поощряйте свободное общение Проектная группа составляет около 10 человек, представляет из себя многопрофильную команду. Участники дополняют друг друга и делят между собой ответственность за проект.

Проектная группа разделяется на шесть ролевых кластеров, соответствующих шести качественно различным задачам проекта.

1. Управление продуктом Представление интересов заказчика; аналитика; обоснование бизнес-отдачи; формирование единого видения и рамок проекта; управление требованиями заказчика; определение приоритетов факторов (время/рамки/ресурсы); PR продукта; план коммуникаций.

2. Управление программой Управление процессом разработки с целью получение продукта в рамках проектных ограничений; формулировка спецификации и разработка архитектуры; управление совещаниями и коммуникациями; формирует сводный план; управление рисками; сетевой график работ; отчётность.

3. Разработка Определяет дизайн решения; оценка времени разработки; разработка; консультирование.

4. Тестирование Планирование тестирования; тестирование.

5. Удовлетворение потребителя Представляет интересы потребителя (на заказчика, а конечного пользователя системы); сбор требований потребителя; формирует требования к эргономике, справочной системе и учебным материалам.

6. Управление выпуском Внедрение; обеспечение сопровождения; материальное обеспечение и логистика; инфраструктура поставок.

Принципы MSF формируют такой подход к управлению проектами, при котором:

* ответственность за управление проектом распределенная между лидерами ролевых кластеров внутри команды — каждый член проектной группы отвечает за общий успех проекта и качество создаваемого продукта.

* профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней — в эффективно работающей команде каждый ее член имеет необходимые полномочия для выполнения своих обязанностей и уверенный, что получит от коллег все необходимое.

Версия модели процессов в IBM.

Выделяются следующие роли:

1. Заказчик. Инициатор разработки.

2. Планировщик ресурсов. Выдвижение и координация требований к проектам организации, финансовых, трудовых и технических ресурсов.

3. Менеджер проекта. Развитие проекта в целом, гарантирует, что распределение позволит выполнить проект.

4. Руководитель команды. Техническое руководство командой в процессе выполнения проекта.

5. Архитектор. Отвечает за проектирование архитектуры системы.

6. Проектировщик системы. Проектирование подсистемы, определяет интерфейсы взаимодействия с другими компонентами системы.

7. Эксперт предметной области. Сфера приложения и ее изучение, поддерживает направленность проекта на решение задач в данной области.

8. Разработчики, в том числе информационной поддержки. Создание документации.

9. Специалист по пользовательскому интерфейсу. Эргономика.

10. Тестировщик. Проверка функциональности, качества, эффективности продукта.

11. Библиотекарь. Создание и ведение общей библиотеки проекта.

Регламент для совмещения ролей:

1. Не допускать совмещения ролей, которые имеют конфликтные или противоречивые интересы.

2. Предоставлять роли таким образом, чтобы стимулировать скорость выполнения задачи.