Структура методологии разработки/внедрения программного обеспечения

Тимлидерское. Одним из ключевых факторов успеха проекта является правильное построение процесса или, как иногда говорят, правильный выбор методологии. В статье на Википедии приведена структура методологии, взятая из философии. Если же спуститься с небес на Землю, то можно заметить, что любая методология разработки/внедрения программного обеспечения имеет следующую структуру и отвечает на следующие вопросы:

• Что?
  Что мы делаем: разрабатываем новое ПО с нуля, занимаемся офшорным программированием, внедряем готовую систему или всего понемножку.
  
  
• Кто?
  Состав команды, выполняющей проект. Например: бизнес-аналитик, системный аналитик, архитектор, разработчики, тестировщики, технический писатель.
  
  
• Как?
  Основные этапы и принципы организации процесса. Например, процесс итерационный, каждая итерация длится 2-4 недели и заканчивается поставкой новой версии заказчику. Итерация состоит из этапов анализа, проектирования, разработки, тестирования, внедрения.
  
  Стоит заметить, что некоторые методологии, например Oracle Unified Method, идут дальше и предлагают подробный состав работ. При этом в описании каждой работы приведен еще и шаблон документа, которым должно заканчиваться исполнение данной работы.
  
  
• Обряды
  В каком-то смысле это часть ответа на вопрос "Как?". Обряд - это важное для успеха проекта по мнению участников действие. Например, ежедневные пионерские линейки.
  
  
• Внутренние артефакты
  Внутренние артефакты - средства коммуникации внутри команды. Это может быть доска с диаграммой сгорания задач, техническое задание, спецификация информационных потоков и т.д.
  
  
• Внешние артефакты
  По-сути, это - то, чем команда будет отчитываться перед заказчиком. В российских реалиях это обычно следующие документы: технические требования, техническое задание, эскизный проект, технический проект, рабочий проект, программа и методика испытаний, протокол испытаний.
  

Собственно зачем я это все написал.
Во-первых, выбор методологии, особенно ответы на вопросы "Кто?" и "Как?", существенно влияет на оценку длительности и стоимости проекта. Одно дело, если у нас есть сильные аналитики и мы можем сделать проект по RUP в одну итерацию и совсем другой расклад получается, если предметная область для нас новая, поэтому мы выбираем Scrum и первые пол года будем только переделывать написанное ранее.

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

Если вы не согласны и у вас свои взгляды на процесс разработки, то добро пожаловать в комментарии.

P.S. Для затравки:

• Экстремальное программирование - реальность и мифы.
  
• Обзор методологии Scrum.
  
• Методология Oracle Unified Method.

Понравилось сообщение - подпишитесь на блог и Twitter

Координация родительских и дочерних BPEL-процессов. Сигналы

Продолжаем серию уроков по BPEL. Сегодня мы рассмотрим специфическое для Oracle SOA Suite средство организации взаимодействия между экземплярами BPEL-процессов - сигналы.

Постановка задачи координации родительских и дочерних процессов

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

Взаимодействие с BPEL-процессами реализуется точно так же, как и с другими сервисами. При этом существует три основных паттерна взаимодействия родительского и дочерних процессов:

1. Родительскому процессу интересен только факт запуска экземпляров дочерних процессов. Данный паттерн так же называется "Вызови и забудь" (fire and forget). Родительский процесс создает один или несколько экземпляров дочернего процесса, при этом его не интересует их последующее исполнение.
2. Родительскому процессу интересна информация, возвращаемая дочерними. В таком случае родительскому процессу необходимо ожидать ответ от каждого из них. В случае синхронного взаимодействия ответ и так подразумевается, а в случае асинхронного - родительский процесс продолжает работу после получения ответа от дочернего, а для связывания запроса и ответа используется механизм корреляции или WS-Addressing.
3. Родительскому процессу интересен факт завершения выполнения некоторых действий дочерним процессом, но не результаты этого выполнения. Т.е. родительский процесс нуждается не в сообщении от дочернего, а в некотором сигнале.

Действия Signal и Receive Signal - Oracle'овое расширение языка BPEL - позволяют реализовать третий паттерн взаимодействия процессов.

Длительно выполняющиеся транзакции в BPEL. Механизм компенсаций

Язык Business Process Modeling and Execution Language (BPEL, читается «БИПЛЬ») предназначен для моделирования бизнес-процессов предприятия посредством оркестровки сервисов. При этом, как исполнение самих операции сервисов, так и принятие решения о том, какой именно сервис вызвать, могут занимать довольно длительное время: часы, дни, недели. Особо характерна большая длительность операций в том случае, если они выполняются пользователями.

Ситуация осложняется тем, что зачастую длительно выполняющиеся операции не являются независимыми друг от друга, а представляют собой бизнес-транзакцию. Т.е. в случае возникновения ошибки при выполнении операции необходимо откатить результаты успешно выполненных ранее операций. При этом, из-за высокой длительности операций системные транзакции использовать нельзя. К счастью, язык BPEL предлагает решение проблемы организации бизнес-транзакций - механизм компенсаций.

Уровни сложности сервисов

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

Мониторинг производительности Oracle SOA Suite

Основным инструментом для мониторинга производительности Oracle SOA Suite является Oracle Enterprise Manager Fusion Middleware Control Console (в дальнейшем - EM). Предлагаю рассмотреть основные возможности данного инструмента.

Обеспечение гарантированного порядка обработки сообщений в кластерном окружении с помощью JCA-адаптеров Oracle SOA Suite

В данной заметке описано как настроить JCA-адаптеры Oracle SOA Suite для обеспечения гарантированного порядка обработки сообщений в кластерном окружении.

При интеграции информационных систем, особенно унаследованных, часто приходится обеспечивать взаимодействие с ними через базу данных. В состав Oracle SOA Suite входят адаптеры, реализованные с помощью технологии JCA, позволяющие считывать события из базы данных. Примерами таких адаптеров являются DB- и AQ-адаптеры.

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

Асинхронные веб-сервисы

В данной статье описаны подходы к реализации асинхронного взаимодействия между информационными системами с помощью веб-сервисов. Подробно рассмотрен применяющийся в Oracle SOA Suite подход, основанный на использовании сервиса обратного вызова и стандарта WS-Addressing. Приведены примеры создания асинхронного веб-сервиса с помощью Oracle SOA Suite и генерации клиента к такому сервису с помощью интегрированной среды разработки Oracle JDeveloper.

Введение

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

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

В Oracle SOA Suite применяется второй подход: потребитель сервиса является одновременно поставщиком сервиса обратного вызова. В свою очередь поставщик сервиса после получения запроса от потребителя возвращает ему HTTP-ответ 202 Accepted, что обозначает успешное принятие запроса на обработку. В Oracle SOA Suite при этом создается новый экземпляр композита. После завершения обработки запроса, которая может занимать достаточно много времени, например недели, что особенно характерно, если в обработке запроса участвуют люди, поставщик сервиса осуществляет вызов сервиса обратного вызова, предоставляемого потребителем.