понедельник, 18 июня 2012 г.

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

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

  • Что?
    Что мы делаем: разрабатываем новое ПО с нуля, занимаемся офшорным программированием, внедряем готовую систему или всего понемножку.

  • Кто?
    Состав команды, выполняющей проект. Например: бизнес-аналитик, системный аналитик, архитектор, разработчики, тестировщики, технический писатель.

  • Как?
    Основные этапы и принципы организации процесса. Например, процесс итерационный, каждая итерация длится 2-4 недели и заканчивается поставкой новой версии заказчику. Итерация состоит из этапов анализа, проектирования, разработки, тестирования, внедрения.

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

  • Обряды
    В каком-то смысле это часть ответа на вопрос "Как?". Обряд - это важное для успеха проекта по мнению участников действие. Например, ежедневные пионерские линейки.

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

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

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

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

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

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

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

суббота, 16 июня 2012 г.

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

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

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


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

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

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

понедельник, 11 июня 2012 г.

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

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

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