Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - alex6565

Страницы: « 1 2 3 4 5 6 7 8 9 10 »
121
to ida:
спасибо, ответ был предсказуем

Коллеги, огромное спасибо всем, кто принял конструктивное участие в этом обсуждении. Все, сказанное вами для меня очень важно, независимо от того, совпадает это с моими представлениями или нет.
Я думаю, данная  тема себя исчерпала, я закрываю тему.

122
Вы не понимаете разницу между требованиями, бизнес-требованиями и бизнес-правилами?
Эх, жаль я больше семинары не веду :)
Очень серьезное обвинение! Снизойдете до более подробного объяснения?

Нда... только аналитики могут две страницы обсуждать такие мелкие детали :)
Вопрос был о практическом опыте, с конкретной детализацией вопроса. В процессе обсуждения были коментарии, напряму не относящиеся к предмету вопроса, но тем не менее, показавшие разницу в основополагающих взглядах. Мы обсудили эти разногласия.

Привожу простой пример.

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

По первому вопросу использовалась правовая система и cbr.ru, по второму - интервью, по третьему - запрос и чтение соответствующих документов. Это к вопросу о КАК.

Честно говоря, придумать какие-то другие источники мне трудно - если кто-то знает, с большим удовольствием расширю свои профессиональные горизонты. :)
Здорово, что у вас все-таки был практический опыт работы с БПр! Вероятно вам не составит труда поделиться информацией не только об источниках этих самых БПр (это, как бы, очевидно), но и о том, как вы с ними работали. Просто, на всякий случай, уточню: "КАК" не подразумевает запросить документ, открыть документ, прочитать документ и т.д.
"Как" означает:
 - какие типы БПр вы собирали (классифицировали)?
 - какие методы вы использовали для формулирования БПр (RuleSpeak, SBVR или что-то еще)?
 - работали ли вы с фактами?
 - формировали ли вы набор бизнес терминов
 - какими программными средствами вы пользовались для регистрации и хранения БПр (RuleExpress, DROOLS, что-то другое...)

Мы все будем вам очень благодарны, если вы наконец-то внесете хотя бы небольшой элемент конкретики в нашу пустую болтовню!!!
Спасибо!

PS очень прошу не писать, например: "У Вигерса определены следующие типы БПр...". Не нужно, я знаю, что написано у Вигерса. Вопрос, какие типы создавали именно вы. И так далее по остальным вопросам.

123
Бизнес-требования - это функциональные требования достаточного высокого уровня.
Да, Эдуард, прошу прощения!
Вот эту фразу я прочитал как "Бизнес-правила - это функциональные требования достаточного высокого уровня"
Виноват! Стар стал, глаза уже не те! :)

124
Уважаемый коллега!
Я могу ошибаться, но приложение LUXProject - это внутренний продукт компании Luxoft, используемый данной компанией во внутренних целях. Данный форум собрал специалистов, работающих в большом количестве различных компаний и не только Москвы.
Я думаю, что на ваш вопрос вам может ответить ваш PM, или ваш куратор, если вы только начали работу в Luxoft.
Еще раз прошу прощения, если я ошибся! :)

125
Коллеги,

Чтобы не путать сокращение бизнес-процессов и бизнес-правил, давайте первое сокращать БП, а второе - БПр.
Принято, будем использовать БПр или BR.

Не уверен, что прав, но.

Бизнес-требования - это функциональные требования достаточного высокого уровня.
Эдуард, опять не согласен! Что такое функциональные требования, я уже писал об этом выше, это тот набор требований, кторые выдаются непосредственно в разработку. Это постулат, декларация о необходимости реализации конкретного функционала. Каждое из таких требований должно быть:
  • правильно, т.е. понятно для команды разработчиков сформулировано
  • разработано
  • протестировано
Подчеркиваю, каждое.
Что такое "функциональные требования достаточного высокого уровня". Это должно разрабатываться или нет?! Разве возможен подобный диалог между аналитиком (А) и девелопером (Д):
Д - это что такое?! Как это реализовывать?!!!
А - А, не парься, это высокоуровневые концептуальные функциональные требования!
Д - И чего?!!! Мне это разрабатывать или нет?!!!
А - А, хрен его знает!
 :)
В моем понимании, высокоуровневыми, концептуальными могут Бизнес Требования - это то, что определяет цели и границы системы. То, что определяется в начале проекта, и очень желательно в последствии не менять, иначе проект никогда не закончится.


Бизнес-правила - специализированный вид логики, описывающей ограничения на образ действий, которые система или люди должны учитывать в своем поведении. Бизнес-правила определяются целым рядом факторов, включая директивы распорядительных органов, промышленные стандарты, деловую хватку и простой здравый смысл., т.е. носят нефункциональный характер.
прошу прощения, если цепляюсь к словам, но просто хочется ясного понимания. "Функциональные" требования носят "нефункциональный характер"?!
Мое убеждение, БПр существуют объективно независимо от того, есть ли по этому поводу требование, реализовано ли это требование, вообще возможно ли это требование реализовать.

Очевидно, нельзя говорить, что бизнес-требования = бизнес-правила. Но не следует их и противопоставлять. Имхо они в ортогональных плоскостях.
Мне больше близка картина, когда Бизнес Требования являются некоторой большой фигурой, которой можно накрыть множество точек отдельных БПр. Объективно, существует бесконечное количество БПр за пределами этой фигуры (за рамками проекта), но нам они не интересны.
Действительно задача аналитика перевести с языка бизнеса на язык системы.

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

Если БП много и ими нужно эффективно управлять, действительно лучше определять их в одном месте, например в таблице, а во всех местах ссылаться на идентификатор бизнес-правила
С этим абсолютно согласен
Эдуард, спасибо! :)

126
Я надеялся, что я выражаю точку зрения Бизнес\Системного Аналитика, который "переплавляет" бизнес - "хотелки" заказчика в конкретную постановку для разработчика

127
Денис, привествую! Спасибо за за участие в теме!
Постараюсь ответить по порядку:
@alex6565

По методам работы с бизнес-правилами
Мне в основном попадались системы, где число бизнес-правил было невелико, поэтому я их текст размещал в так называемых "слотах" описаний способов применения, как это рекомендует Хлебников. Также мне кажется полезным приём, который пропагандирует Вигерс в своих примерах, когда перечень бизнес-правил идёт отдельным разделом документа, а из текстов способов применения идут ссылки на идентификаторы бизнес-правил.
О Хлебникове пока не слышал, обязательно ознакомлюсь. Что касается Вигерса, не хочу выглядеть его бездумным аппологетом  :) , но этот его подход мне тоже близок.
По отнологии понятия "бизнес-правила"
Согласно тому же Вигерсу, бизнес-правила являются подмножеством нефункциональных требований уровня пользователя (см. главу 1 книги "Sofware Requirements", раздел Levels of Requirements). Ваших аргументов почему это не так не увидел.
Сложно спорить с таким корифеем, как Вигерс! :) В моем понимании, "бизнес-правила являются подмножеством нефункциональных требований уровня пользователя" озаначает лишь то, что эта информация приходит от пользователя и должна быть так или иначе учтена в разработке. Но, требованием, идущим непосредственно в разработку, или функциональным требованием, это не может являться. Аргументы я привел в предыдущем ответе.

По связи с техническими требованиями
Согласен с Денисом Ивановым, что бизнес-правила могут быть покрыты определёнными техническими функциями системы. Однако считаю важным отделять одно от другого и управлять как бизнес-, так и пользовательскими и техническими требованиями. Потому что, опять же, одно бизнес-правило может быть покрыто множеством пользовательских и технических решений.
Подписываюсь под каждым словом!

По формулировкам названий и шагов способов применения
На основе своего опыта смею утверждать, что более полезно, чтобы названия способов применения и шагов его сценариев отражали логическое условие, истинность которого соответствовала интересам агента/заинтересованного лица, чьи интересы защищаются в данном способе применения. Иначе говоря, формулировки шагов и названий способов применения должны быть ориентированы не на процесс (проверить; искать), а на позитивный результат (убедиться, что; найти).
Также, абсолютно согласен! Скажу более, в предыдущем проекте я настаивал, и это было отражено в моем докладе на семинаре, что каждый сценарий использования (Use Case) должен соотвествовать одной задаче пользователя (User Goal, оно же User Requirement), естественно возможна ситуация, когда одна, достаточно сложная, задача пользователя раскрыта несколькими сценариями использования. Т.е., сценарий использования должен описывать последовательность действия оператора системы (и отклики системы), для достижения конкретной задачи пользователя (печать месячного отчета, создание платежного документа и т.д.) 

128
Типичные функциональные требования низкого уровня.
Примерные названия use cases:
1 проверить права доступа
2 проверить срок действия электронной карты
Денис, спасибо, что откликнулся!
Я не соглашусь с тобой, что бизнес правила, даже описанные мной в примере, - это требования.  Первая и главная разница: БП - это положение, знание о бизнесе. Правило, принятое в конкретной организации. Оно существует независимо от того, автоматизирован их бизнес, или они работают на счетах, а на входе сидит бабушка - вахтерша.
Требование - это: "Функциональность, необходимая пользователю для решения проблемы или достижения цели" (IEEE, выдержка взята из твоей книги "Моделирование на UML, теория, практика, видеокурс", которую я сейчас с огоромным интересом "грызу"). Т.е. требование (функциональное) - это описание функционала в автоматизированной системе.
Эти вещи связаны? Безусловно! Это одно и то же? Нет!
Очень наглядно разница между БП и требованием показана в статье: http://www.brcommunity.com/b290.php (я уже давал на нее ссылочку ранее).
Там приведен набор вопросов, позволяющих понять, что БП и требования - это не одно и то же:
Цитата: GLADYS S.W. LAM link="http://www.BRCommunity.com/a2006/b290.html"
Here are some questions for the readers:
Do the rules exist even when you can't implement the requirement?  Absolutely.
Will implementing the requirement mean all the rules will be complied with?  Not for sure.
Is this the ONLY feasible requirement to enable compliance with this set of rules?  No.
Более того, формулирование БП подчиняется особым законам, описанным в Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/PDF
Есть еще аргументы, касающиеся работы с фактами и терминами, но, мне кажется, пост и так уже перегружен.
Денис, еще раз спасибо за отклик. Хочу отдельно сказать спасибо за очень полезную книгу!  Книга действительно - Must Have!

129
большая часть моих требований как заказчика решения формулируются именно как бизнес правила.
согласен с каждым словом.
Ведь, смотрите, простейший пример: система пропуска на территорию компании, мы все каждый день сталкиваемся с необходимостью прикладывать карточку к ридеру.
Простейший Use Case, описывающий операцию авторизации сотрудника, можно описать двумя-тремя фразами:
 1 сотрудник прикладывает карточку к ридеру;
 2 система считывает информацию с карточки;
 3 система проверяет валидность учетной записи;
 4 в случае валидности система открывает дверь (вертушку)...
Пункты 2-4 прямые кандидаты на формулировку функциональных требований.
Но!
Но, существует и другая информация, например:
 1 сотрудники данной категории не имеют право работать в нерабочие дни
 2 срок действия электронной карты ограничивается 1 годом
 и т.д.
Очевидно, что игнорировать данную информацию мы не можем - это обязательно должно быть учтено в реализации.
Включать это в Use Case? Мне кажется это не очень корректно. Включать это в требования, но эти правила могут относиться к общекорпоративным правилам и могут одновременно распространяться и на другие системы авторизации, например учетная запись пользователя рабочей станции тоже должна подчиняться данным правилам.
Очевидно, что все подобные вещи должны быть вынесены в отдельные категории знаний, но иметь четкое указание, где они используются.
Я сейчас не затрагиваю вопросов описания фактов, которые просто содержат нужную информацию об автоматизируемом бизнесе, но напрямую в требованиях могут быть не задействованы. И я не говорю о такой важной вещи, как фиксации "терминов", т.е. определении основных бизнес понятий для того, что бы с заказчиком разговаривать на одном "бизнес" языке.
Тема, на самом деле очень интересная и, как мне кажется, немного недооцененная. Очень хочу ошибиться в этом суждении! :)

130
Александр, Вы не противоречите сами себе? Тема носит название Кто занимается сбором Бизнес Правил (Business Rules).
Пардон!!! :)
Имелось в виду: "Кто из присутствующих на форуме... сейчас (или ранее) занимается (занимался) сбором... У кого есть опыт в этой области?"
Это не означает, Кто должен. Это означает: Кто сейчас этим реально занимается
Прошу прощения за неточную формулировку вопроса :)

131
Александр по поводу бизнес-правил есть информация ...
Эдуард, большое спасибо за ссылки, обязательно просмотрю все. Более того, я могу добавить в этот список еще хорошую порцию ссылок :)
Но, наверное повторюсь, мне было бы интересно узнать именно о практическом опыте работы с BRules. Мне интересно понять насколько именно российское сообщество аналитиков оценивает важность (или неважность) этого аспекта.

132
Бизнес-правила это одна из разновидностей требований.
С этим абсолютно не согласен, поэтому и уточнил в своем вопросе. Есть достаточно большое количество работ, посвященных описанию разницы между Business Requirements и Business Rules. Вот например, самый простой и забавный образчик: http://www.brcommunity.com/b290.php
Следовательно их вполне может собирать тот же, кто собирает требования :)
С этим сложно спорить, тем более, что это уже, наверное, решается в каждой конкретной компании - кто будет заниматься сбором и управлением правилами. Очевидно, что Бизнес-Аналитик - это лучшая кандидатура на эту работу.
Но, это не является предметом моего интереса. Мне интересно, именно, КАК а не КТО
Спасибо!

133
Александр, спасибо за ответ!

134
Коллеги, мне очень важна информация, кто-нибудь имеет опыт работы с бизнес правилами (BR). Я имею в виду сбор, формулирование правил, формирование глоссария бизнес терминов, и т.д.
Рискую получить канделябром по голове за очевидные вещи, но на всякий случай все-таки уточню - речь идет не о бизнес требованиях, а именно от правилах.
Если таковой опыт имеется, поделитесь пожалуйста, какими методами вы пользуетесь при формулировании правил, какие вообще типы правил регистрируете, как в дальнейшем используете при работе с требованиями, какие тулзы используете для сбора, хранения и управления терминами и правилами.

Спасибо!
 

135
Григорий, с запозданием присоединяюсь к прогрессивному человечеству!!! Всего самого наилучшего и удачи!!!

Страницы: « 1 2 3 4 5 6 7 8 9 10 »