Проектирование (Elaboration)

· Документирование требований (включая детальное описание для большинства прецедентов).

· Спроектированную, реализованную и оттестированную исполняемую архитектуру.

· Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

· Сниженные основные риски.

Построение (Construction)

Во время этой фазы происходит реализация большей части функциональности продукта.

 4. Внедрение (Transition)

Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта.

49. Технология RAD.

Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

· небольшую команду программистов (от 2 до 10 человек);

· короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

· фаза анализа и планирования требований;

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

· фаза проектирования;

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

· фаза построения;

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

· фаза внедрения.

На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой).

 

Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

 

50. Основные принципы экстремального программирования.

Экстремальное программирование – упрощенная методика организации производства для небольших и средних по размеру команд специалистов, занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся требований.

Кэнт Бэк предложил 12 практик:

1. Игра в планирование – Planning Game.

2. Тестирование.

3. Программирование парами.

4. Рефакторинг - методика изменения кода без изменения его функциональности.

5. Простой дизайн – simple design

6. Коллективное владение кодом

7. постоянная интеграция – несколько раз в день

8. Наличие заказчика в команде

9. Частые выпуски версий

10. 40 часовая рабочая неделя

11. Стандарт кодирования

12. метафора системы

51. Моделирование бизнес-процессов (BPM)

BPM - Business process modeling

BPM - Business process management

Две части систем управления бизнес процессами, которые соответствуют трем стадиям – проектирование, исполнение и мониторинг.

Проектирование – разработка схем бизнес процессов. Этот этап поддерживается графическим редактором и репозитарием (для хранения модели бизнес процессов и организации доступа к этим моделям).

Исполнение.

Основной инструмент – ядро системы управления бизнес процессом - BPM engine. Он экземпляры бизнес процессов, отслеживает состояния, хранит значения реквизитов, выполняет бизнес правила.

Мониторинг.

Осуществляет контроль бизнес процесса.

Две реализации интерфейса мониторинга: перечень задач и тот, который показывает на какой стадии выполнения находится задача.

Основные технологии, которые используются для функционирования систем управления процессами:

1. язык XML – разрозненные данные можно описать единообразно и использовать это описание в различных компонентах системы

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

3. интеграция корпоративных приложений

4. веб-сервисы – конкретные задачи, которые необходимо решать.

52. Управление бизнес-процессов (BPM)

При управлении три составляющие:

В данном случае BPM – процесс установления соответствий между целями задачами бизнеса и средствами выработки управляющих компонентов.

В связи с этим BPM можно представить в виде 3х основных компонентов:

1. непрерывный мониторинг БП

2. фиксация тех ситуаций, когда показатели БП не соответствуют представлениям и установкам об эффективности

3. выполнение корректирующих управляющих действий

 

 

53. Выполнение бизнес-процессов (BPM)

 

Выполнение

1) Один из способов автоматизировать процессы состоит в приобретении и развитии специальных приложений, которые автоматически выполняли бы необходимые шаги процесса.

Однако на практике эти приложения редко выполняют все шаги процесса полностью и с абсолютной точностью.

2) Другой подход использует так называемый сочетание программного обеспечения и человеческого вмешательства.

Однако этот подход более сложен из-за достаточно сложного процесса организации документации.

 

3) Чтобы решить эти проблемы программное обеспечение было развито таким образом, чтобы появилась возможность определять бизнес-процессы на компьютерном языке, выполняемом непосредственно но компьютере.

Система использует функции приложений для выполнения бизнес-операций. А когда шаги становятся слишком сложными, система запрашивает человеческого вмешательства в процесс.

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

4) Также системы используют бизнес-правила с целью обеспечения управления поведением процессов.

54. Стандарт моделирования бизнес-процессов BPMN

BPML

Нотация поддерживает 4 категории элементов:

1. объекты потока управления (события, действия и логические операторы)

2. соединяющие объекты (поток управления, поток сообщений, ассоциации)

3. роли (пулы и дорожки)

4. артефакты (данные, группы и текстовые аннотации)

Объекты одного типа могут быть в 4 состояниях:

1. начальное

2. промежуточное – обработка, генерация

3. завершающее

СОБЫТИЯ

События изображаются окружностью и означают какое-либо происшествие в мире. События инициируют действия или являются их результатами. Согласно расположению в процессе события могут быть классифицированы на начальные (start), промежуточные (intermediate) и завершающие (end).

· Простые события (plain events) это нетипизированные события, использующиеся, чаще всего, для того, чтобы показать начало или окончание процесса.

· События-сообщения (message events) показывают получение и отправку сообщений в ходе выполнения процесса.

· События-таймеры (timer events) моделируют события, регулярно происходящие во времени. Также позволяют моделировать моменты времени, периоды и таймауты.

· События-ошибки (error events) позволяют смоделировать генерацию и обработку ошибок в процессе. Ошибки могут иметь различные типы.

· События-отмены (cancel events) инициируют или реагируют на отмену транзакции.

·

· События-компенсации (compensation events) инициируют компенсацию или выполняют действия по компенсации.

· События-условия (conditional events) позволяют интегрировать бизнес правила в процесс.

· События-сигналы (signal events) рассылают и принимают сигналы между несколькими процессами. Один сигнал может обрабатываться несколькими получателями. Таким образом, события-сигналы позволяют реализовать широковещательную рассылку сообщений.

· Составные события (multiple events) моделирует генерацию и моделирование одного события из множества.

· События-ссылки (link events) используются как межстраничные соединения. Пара соответствующих ссылок эквивалентна потоку управления.

· События-остановы (terminate events) приводят к немедленному завершению всего бизнес процесса (во всей диаграмме).

ДЕЙСТВИЯ

Действия изображаются прямоугольниками со скругленными углами. Среди действий различают задания и подпроцессы. Графическое изображение свёрнутого подпроцесса снабжено знаком плюс у нижней границы прямоугольника.

 

· Задание (task) это единица работы, элементарное действие в процессе.

· Множественные экземпляры (multiple instances) действия показывают, что одно действие выполняется многократно, по одному разу для каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действия могут выполняться параллельно или последовательно.

· Циклическое действие (loop activity) выполняется, пока условие цикла верно. Условие цикла может проверяться до или после выполнения действия.

· Свёрнутый подпроцесс (collapsed subprocess) является сложным действием и содержит внутри себя правильную ДБП.

· Развёрнутый подпроцесс (expanded subprocess) также является составным действием, но скрывает детали реализации процесса.

· Ad-hoc подпроцесс (ad-hoc subprocess) содержит задания. Задания выполняются до тех пор, пока не выполнено условие завершения подпроцесса.

УСЛОВИЯ

Логические операторы изображаются ромбами и представляют точки принятия решений в процессе. С помощью логических операторов организуется ветвление и синхронизация потоков управления в модели процесса.

· Оператор исключающего ИЛИ управляемый данными (data-based exclusive gateway) Если оператор используется для ветвления, то поток управления направляется лишь по одной исходящей ветви. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.

· Оператор исключающего ИЛИ управляемый событиями (event-based exclusive gateway) направляет поток управления лишь по той исходящей ветви, на которой первой произошло событие. После оператора данного типа могут следовать только события или действия-обработчики сообщений.

· Оператор И (parallel gateway), использующийся для ветвления, разделяет один поток управления на несколько параллельных. При этом все исходящие ветви активируются одновременно. Если оператор используется для синхронизации, то он ожидает завершения выполнения всех входящих ветвей и лишь затем активирует выходной поток.

· Оператор включающего ИЛИ (inclusive gateway) активирует одну или более исходящих ветвей, в случае, когда осуществляется ветвление. Если оператор синхронизирует потоки, то он ожидает завершения выполнения всех активированных ветвей и затем активирует выходной поток.

· Сложный оператор (complex gateway) имеет несколько условий, в зависимости от выполнения которых активируются исходящие ветви. Оператор затрудняет понимание диаграммы, так как условия, определяющие семантику оператора, графически не выражены на диаграмме. Вследствие этого использование оператора нежелательно.

СОЕДИНЯЮЩИЕ ОБЪЕКТЫ

 

Поток управления

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

АССОЦИАЦИИ

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

РОЛИ

Пулы - изображаются прямоугольником, который содержит несколько объектов потока управления, соединяющих объектов и артефактов. Дорожки - представляют собой часть пула. Дорожки позволяют организовать объекты потока управления, связывающие объекты и артефакты.

АРТЕФАКТЫ

Артефакты позволяют разработчикам отображать дополнительную информацию в диаграмме. Это делает диаграмму более читабельной и насыщенной информацией. Существуют три предопределённых вида артефактов: Данные - показывают читателю какие данные необходимы действиям для выполнения и какие данные действия производят. Группа - изображается прямоугольником с закругленными углами, граница которого — штриховая линия. Группа позволяет объединять различные действия, но не влияет на поток управления в диаграмме.

Текстовые аннотации - используются для уточнения значения элементов диаграммы и повышения её информативности.

Данные

Группа

Текстовая аннотация

55. Модельно-ориентированный подход к разработке ПО

Model Driven Architecture (MDA) — создаваемая консорциумом OMG концепция модельно ориентированного подхода к разработке программного обеспечения. Его суть состоит в построении абстрактной метамодели управления и обмена метаданными (моделями) и задании способов ее трансформации в поддерживаемые технологии.