- •Двусторонние шпоры по файзу
- •Печатай прямо этот файл
- •1. Общая характеристика процесса проектирования асоиу. Цели и этапы разработки консалтинговых проектов
- •2. Разработка системного проекта на основе стандарта iso 12207. Основные процессы жизненного цикла программного обеспечения асоиу.
- •3. Модели жизненного цикла программного обеспечения асоиу. Подход rad.
- •3. Методология rad
- •Основные принципы методологии rad
- •4. Структурный подход к проектированию информационной системы. Функциональная модель асоиу. Количественный анализ диаграмм idef0 и dfd.
- •5. Объектно-ориентированный подход к анализу и проектированию информационной системы. Унифицированный язык моделирования uml.
- •6. Моделирование бизнес-процессов спецификация требований на основе структурного подхода.
- •7. Моделирование бизнес-процессов спецификация требований на основе объектно-ориентированного подхода. Методика rup.
- •8. Разработка модели защиты данных в асоиу
- •9. Управление проектом асоиу
- •10. Проектная документация асоиу. Требования госТов к документации, содержание документации.
- •11. Инструментальные средства проектирования асоиу.
- •12. Типизация проектных решений асоиу. Использование коробочных продуктов и адаптируемых интегрированных систем.
- •Самостоятельная разработка
- •Заказные системы
- •Тиражируемые (коробочные) продукты
- •Адаптируемые интегрированные системы
- •Адаптируемые интегрированные системы как платформа современных комплексных систем автоматизации
- •13. Графические средства представления проектных решений асоиу (idef, dfd, uml, erd и т.Д.)
- •14. Классификация ис
- •15. Рынок ис
- •16. Методы проектирования ис
- •17. Каноническое проектирование
- •18. Типовое проектирование
- •19. Предпроектное обследование предприятий
- •1. Анкетирование
- •2. Сбор документов
- •3. Интервьюирование
- •20. Этапы проектирования ис с применением uml
- •21. Модель процессов msf (тут же про опыт ibm)
- •22. Сертификация и оценка процессов создания по. Модель зрелости cmm.
- •23. Сертификация и оценка процессов создания по. Методика spmn.
- •9 Лучших навыков, рекомендованных spmn.
- •5. Качество продукта должно контролироваться на детальном уровне.
- •8. Конфигурационное управление.
- •24. Парадигма Бейзили
- •25. Проектирование бд
- •26. Распределенная обработка данных
- •27. Системное проектирование программных систем на основе стандартизации
- •28. 34 Компетенции для Управления Проектом
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.
Выделяются следующие роли:
-
Заказчик. Инициатор разработки.
-
Планировщик ресурсов. Выдвижение и координация требований к проектам организации, финансовых, трудовых и технических ресурсов.
-
Менеджер проекта. Развитие проекта в целом, гарантирует, что распределение позволит выполнить проект.
-
Руководитель команды. Техническое руководство командой в процессе выполнения проекта.
-
Архитектор. Отвечает за проектирование архитектуры системы.
-
Проектировщик системы. Проектирование подсистемы, определяет интерфейсы взаимодействия с другими компонентами системы.
-
Эксперт предметной области. Сфера приложения и ее изучение, поддерживает направленность проекта на решение задач в данной области.
-
Разработчики, в том числе информационной поддержки. Создание документации.
-
Специалист по пользовательскому интерфейсу. Эргономика.
-
Тестировщик. Проверка функциональности, качества, эффективности продукта.
-
Библиотекарь. Создание и ведение общей библиотеки проекта.
Регламент для совмещения ролей:
-
Не допускать совмещения ролей, которые имеют конфликтные или противоречивые интересы.
-
Предоставлять роли таким образом, чтобы стимулировать скорость выполнения задачи.
-