- •1.2.Начало 70-х годов - “software crisis” (кризис по)
- •3.Категории современных проектов
- •4. Проблемы сегодняшнего дня
- •5. Экстремальные проекты
- •6. Сопровождение
- •7. Принципы оценки технологий (Agile Software Development)
- •8. Модель смм
- •9.Основные направления развития современных технологий
- •11.Жизненный цикл по. Процессы и модели
- •13. Процесс разработки по
- •14. Процесс управления конфигурацией (configuration management process) –
- •15. Процесс обеспечения качества (quality assurance process)
- •16. Модель жц по
- •17. Состав стадий полного жц по
- •18 Каскадная модель жц по (waterfall)
- •21.Подход rad (Rapid Application Development) – ibm, James Martin, середина 80-х годов
- •23А. Модели и их роль в создании систем
- •23. Графическое моделирование - средство преодоления сложности больших систем
- •24. Язык моделирования:
- •26. Диаграммы uml (версия 1.Х)
- •27. Технологии создания программного обеспечения
- •28. Технология Rational Unified Process (rup)
- •29. Стадии жизненного цикла по
- •30. Понятие бизнес-процесса
- •31.Области применения бизнес-моделей:
- •32.Многообразие средств моделирования
- •33.Метод sadt
- •34.Преимущества и недостатки idef0
- •35.Метод idef3
- •36.37.Моделирование потоков данных (процессов)
- •38.39.Erd (Entity-Relationship Diagrams) – диаграммы “сущность-связь”
30. Понятие бизнес-процесса
Бизнес-процесс - логически завершенный набор взаимосвязанных и взаимодействующих видов деятельности, поддерживающий деятельность организации и реализующий ее политику, направленную на достижение поставленных целей
Бизнес-процесс использует определенные ресурсы для преобразования входных элементов в выходные
Бизнес-процесс - набор связанных процедур, направленных на достижение определенного результата, представляющего ценность для потребителя
Построение бизнес-моделей: применение различных методов и средств для визуального моделирования бизнес-процесов Цели:
Обеспечить понимание структуры организации и динамики происходящих в ней процессов
Обеспечить понимание текущих проблем организации и возможностей их решения
Убедиться, что заказчики, пользователи и разработчики одинаково понимают цели и задачи организации
Создать базу для формирования требований к будущей информационной системе организации
Модель бизнес-процесса должна давать ответы на вопросы:
Какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата
В какой последовательности выполняются эти процедуры
Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса
Кто выполняет процедуры процесса
Какие входящие документы/информацию использует каждая процедура процесса
Какие исходящие документы/информацию генерирует процедура процесса
Какие ресурсы необходимы для выполнения каждой процедуры процесса
Какая документация/условия регламентирует выполнение процедуры
Какие параметры характеризуют выполнение процедур и процесса в целом
31.Области применения бизнес-моделей:
1. Схема текущей деятельности организации
2. Модель предметной области
3. Общая бизнес-модель как эталон для семейства приложений
4. Типовая бизнес-модель для организаций определенного профиля
5. Описание новых бизнес-процессов
6. Реинжиниринг бизнес-процессов
Методика моделирования бизнес-процессов
Методика включает:
описание методов моделирования - способов представления реальных объектов предприятия при помощи объектов модели;
последовательность шагов по сбору информации, ее обработке и представлению в виде моделей;
типовые формы документов
Многообразие методов моделирования бизнес-процессов
Структурные методы
SADT (Structured Analysis and Design Technique), IDEF0, IDEF3
диаграммы потоков данных (Yourdon, DeMarco, Gane, Sarson)
Метод ARIS
Rational Unified Process
Метод Ericsson, Penker
Popkin Process
…
32.Многообразие средств моделирования
System Architect (Popkin Software)
ARIS Collaborative Suite (IDS Scheer AG)
Corporate Modeler (Casewise)
….
Rational Rose (IBM Rational Software)
Microsoft Visio (Microsoft)
….
Проблемы выбора метода моделирования бизнес-процессов
Проблема выбора стандартной методики (компании продают инструменты, а не методы; обучают системам, а не методикам)
Соответствие задачам проекта (трудно определить заранее, насколько выбранная методика подходит для конкретного проекта)
Сложность регламентации использования инструментальных средств (много возможностей, чем гибче и мощнее система, тем труднее ее корректно использовать)
Отсутствие стандартов и стандартной терминологии
Отсутствие информации, возможностей для реального обмена опытом ведения проектов