Pull to refresh
26
0
Наталья Желнова @enotinka

User

Send message

Можете прийти в телеграм (@nzhelnova) - я дам вам эту хорошую книжку

Посмотрите, например, хорошую книжку:
BPMN Method and Style, with BPMN Implementer’s Guide - A structured approach for business process modeling and implementation using BPMN 2.0 by Bruce Silver
Автор - консультант с многолетним опытом и долгое время занимал одну из руководящих позиций ABPMP

Уважаемый автор, согласно правилам "читаемости" моделей бизнес-процессов, выполненных с использованием нотаций, ориентированных на process flow, ваша модель "ToBe" плохо читаема.
Согласно этим правилам, на одной диаграмме должно размещаться не больше 10 значимых элементов модели бизнес-процесса.

Пересмотрите вашу модель, используйте другие виды диаграмм BPMN - collaboration diagram, choreograpy diagram, чтобы показать взаимодействие между процессами и ролями. Прибегните к разбиению вашей диаграммы процесса на подпроцессы, наконец, чтобы улучшить читаемость.

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

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

Начнем с того, что то, что автор называет "квадратиками" - скорее всего, элементы нотации BPMN 2.0. К BPMS BPMN 2.0 (один из стандартов консорциума OMG) имеет некоторое отношение - BPMN даже своей растущей популярностью обязан BPMS-системам, но это не единственный стандарт моделирования, используемый различными BPMS-платформами. Если бы автор немного погрузился в тему, он обнаружил бы, что упомянутых им "временных диаграмм", которые "привычны для аналитиков", не существует, а список языков описания исполняемых моделей бизнес-процессов, не ограничивается BPMN.
Никаких "временных диаграмм" профессиональный аналитик не составляет. Профессиональный аналитик может составлять следующие виды диаграмм:

* Модели бизнес-процессов (нотации: BPMN, EPC). В том числе - модели исполняемых бизнес-процессов (для тех самых BPMS), которые не обязательно должны содержать пресловутые "квадратики". Есть, например, такие языки формального описания бизнес-процессов, как BPEL, BPML, WPDL, XPDL. Есть языки, ориентированные на оркестрацию web-сервисов (WSCL/WSCI консорциума W3C). Но в моделировании бизнес-процессов часто останавливаются на BPMN 2.0 - просто, наглядно, заменяет Activity diagram (диаграмму деятельности) - кстати, OMG, который поддерживает и развивает стандарт UML, решил объединить два этих вида диаграмм.

Какой бы язык или нотацию ни использовал здесь аналитик, цель у него - дать общее представление о сквозном (end-to-end) процессе, результатом которого будет создание дополнительной ценности/удовлетворение потребности клиента. BPMN 2.0 нагляден и понятен как бизнесу, так и разработчику, именно поэтому BPMS-системы, использующие BPMN 2.0, стали популярны.

Другие виды диаграмм, которые создает аналитик:

* Диаграммы вариантов использования (язык: UML)

* Диаграммы последовательности (язык: UML)

* Диаграммы состояний (язык: UML)

* E-R диаграммы и диаграммы, иллюстрирующие семантику связей между объектами предметной области;

и другие виды диаграмм, относящиеся к дизайну проектируемой системы.

Попытки генерировать исполняемый код на основе UML-диаграмм потерпели фиаско, активные пропагандисты этого подхода - Borland и IBM - отказались от него где-то между 2000 - 2010 гг. А вот с BPMN тема "взлетела", не в последнюю очередь потому, что за основу был взят один из аспектов моделирования - цепочка операций, выполняемых пользователями, а остальные аспекты были скрыты "внутри" платформы. Но "взлетела" она не для тех, чьи навыки ограничиваются "рисованием" комичных картинок и ссылками на "курсы для стартаперов", а для тех, кто, понимая разделение обязанностей между разработчиком и аналитиком, попытался выжать максимум из того, что сможет аналитик за достаточно короткое время.

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

BPMS-системы расширили множество формальных языков, используемых для описания бизнес-процессов и легко транслируемых в код. В создание своих BPMS-платформ инвестировали такие гиганты индустрии, как IBM, Oracle (вспомним его BPM Suite), Microsoft. Как всякая платформа, любая BPMS-платформа имеет ограниченную область применения и не снимает необходимость думать и писать код. Умение использовать BPMS там, где это нужно, чтобы сократить затраты на разработку "с нуля", и не использовать там, где это не нужно, приходит с опытом в индустрии, которого, увы, у автора статьи нет совсем. Опыта у автора даже меньше, чем у Грефа, никогда не ставившего перед Сбером задачу "все бизнес-процессы в Сбере только на BPMS делать", и это чувствуется в каждой букве его статейки (чего стоит уже один этот комичный пассаж "этот BPMS генерит код из xml-файла, что приводит к большим проблемам при работе с контролем версий. Например, после сведения двух версий через git, этот фреймворк вполне может просто удалить весь разработанный код и оставить пустую директорию. Ну типа он конфликты разрешить не смог. Красиво все только, когда Грефу показывают без параллельных веток, без нескольких разработчиков, работающих над приложением"). Автор, вы книжку хоть какую-нибудь про git в руки возьмите - авось, понравится, и вы не будете больше писать смешные глупости в интернете.

А за BPMS можно не беспокоиться. Как всякая новая технология, она пережила период хайпа (примерно в 2010-х), и теперь спокойно используется там, где нужно, теми, кто умеет.

Каждый год ABPMP (международная ассоциация профессионалов в области управления бизнес-процессами) проводит конкурсы "BPM-проект года". В последнее время призовые места стали доставаться opensourse - решениям (Camunda, Activiti, etc.).

Camunda используется для автоматизации части процессов розничного бизнеса в Тинькофф банке, например.
Activiti (доработанная) - в Сбере.



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

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

Путать стандарты качества ПО и модели качества (о которых я говорю, определяя атрибуты качества) и "стандарты по требованиям" - это распространенная ошибка.
Рекомендую больше так не делать.

Отвечу я, как бывший главный аналитик проекта, который был признан "BPM-проектом года" на конкурсе проектов в области BPM в 2017 г. (https://bpmaward.ru/cat/2017/; презентация проекта тут: https://bpmaward.ru/wp-content/uploads/2017/09/Сбербанк-BPM-проект-года.pdf).
0. Термины и определения. BPM - это управление бизнес-процессами (Business process management) - дисциплина. Придумана, чтобы управлять бизнес-процессами процессами (автоматизация - часть управления, и IT видит бизнес-процессы лишь в части задач автоматизации, но как правило, не как полный цикл управления). BPMS - система для управления бизнес-процессами, автоматизирующая исполнение и часть функций управления бизнес-процессами. Их не надо путать.
1. Нам (за счет того, что мы явно разделили работу с данными и работу с задачами на уровне проектируемых процессов, ввели переиспользуемые процессы, продумали, как версионировать процессы, и сделали еще много достаточно толковых вещей) удалось сократить time to market при изменениях в автоматизируемых бизнес-процессах в 1,5 раза.
2. Популярность BPMS в западных странах где-то в 2010-х (после перехода к более-менее осмысленному внедрению BPMS) немного снизилась, а потом опять пошла вверх (думаю, не в последнюю очередь за счет появления отраслевых стандартов и open source движков для BPMS). Клиенты BPMS - банки, страховые компании, медицинские учреждения, телеком - те, кто ведет своих клиентов через достаточно строго регламентированные процедуры. В Европе в конце 2010-х каждый пятый банк внедрял BPMS.
3. Лично я очевидное преимущество BPMS вижу в том, что высоких требований к искусству программирования (т.е. к квалификации) поддерживающих ее программистов они, как правило, не предъявляют (BPMS - это вообще про low code). В общем, толковый аналитик с минимальным опытом программирования на том языке, который используется для написания кода на той платформе, на которой реализована BPMS, вполне справится.
4. Из BPMS в последнее время наибольшую популярность приобретает Camunda (вот и Тинькофф банк, например, нашел для нее нишу; популяризует BPMN 2.0 https://bpmn2.ru/). На сайте https://bpmaward.ru/ можно найти примеры живых внедрений BPMS. Наша, к слову скажем, реализация BPMS до сих пор живее всех живых, является частью платформы Platform V.

Так что опыт разный, отношение к BPMS тоже разное.

Есть три типа систем контроля версий - локальные (это история древнего мира), централизованные и распределенные.
SVN - это централизованная система контроля версий, Git - распеделенная.
Если коротко, то у SVN - наличие взаимоблокировок пользователей, худшая горизонтальная масштабируемость, чем у Git. Но для проектов с "плоской структурой" SVN работает отлично.

Хороший вопрос.
Я думаю, что нынешним летом (но уже ближе к августу) я ее напишу.
«Быстро печатать» — это несомненное преимущество для бизнес-аналитика, равно как и моделировать «во всяких интересных нотациях».

Я удивляюсь, что подобные статьи могут появляться в эпоху, когда существует множество профессиональных ресурсов для бизнес- и системных аналитиков. Хотя бы:
IIBA Russian Chapter Initiative (https://www.facebook.com/groups/IIBARussianChapter/?fref=ts),
Анализ в IT-проектах (https://www.facebook.com/groups/Analiz.v.IT/),
Сообщество аналитиков (http://www.uml2.ru/)
Ну, я бы так не сказала — что он сводится к одной инженерии требований. У классиков жанра это так, однако реальные обязанности аналитика выходят за рамки Requirements Engineering.
Журнал запросов на выполнение работ — на мой взгляд, не самый удачный перевод. Лучше, мне кажется, журнал запросов на изменение.
У «Русской редакции когда-то была мода ставить в информацию об издании фамилию редактора. По крайней мере, свою я там видела, когда редактировала книги по SQL Server (администрирование и разработка). Иногда ставили фамилии переводчиков (по крайней мере я на этом настаивала, когда работала вместе с людьми, которые начинали свой путь в программировании с разработки движков для баз данных).
Теперь эта мода у „Русской редакции“ прошла — они переводят книги силами компании Логрус, занимающейся локализацией разных программных продуктов, в том числе и Microsoft. Работу переводчиков в Логрусе часто выполняют студенты. Что касается редактуры — похоже, что от нее и вовсе отказались.
Да, но разница в том, что бизнес-правило может диктовать, как именно должен выполняться сценарий. Если бы бизнес-правила не существовало, этот сценарий мог бы быть реализован 10-20 различными вариантами. А если оно есть — то только одним.
Это смесь того, «что» и «как». По отношению к сценарию отгрузки товара — это как должна выполняться операция.
Да, собственно, как их классифицировать или делить на категории — это не столь уж принципиально.
Важнее — как их определять, и на что они влияют в системе.
Да, в общем, многое в требованиях является сущностью реального мира. И бизнес-правила, как один из типов ограничений — тоже. И в зависимости от наличия автоматизации и способа автоматизации некоторые бизнес-правила могут меняться.
Считать их разновидностью ограничений, диктующих нам, как реализовывать ту или иную функцию или группу функций — вполне корректно. Если предположить, что водораздел между функциональными и нефункциональными требованиями проходит по линии «что надо сделать (функциональные) — как надо сделать *нефункциональные)», то получится, что ограничения как раз попадают в нефункциональные требования.
Вигерс Карл, Разработка требований к программному обеспечению, Москва, «Русская Редакция», Подписано в печать 03.12.03
Глава 1 стр. 8
Знаменитый рисунок, проводящий границу между функциональными и нефункциональными требованиями:

image

Думаю, что на основании этой картинки (там еще текст к ней есть) можно однозначно сказать, к какому виду требований относит Вигерс бизнес-правила.

Да, атрибуты качества — это, собственно, основная часть нефункциональных требований при разработке ПО. Поэтому ей уделяется так много внимания — это я про Макконнела. Про остальные виды нефункциональных требований вообще пишут мало. Про то, как их определять — практически никто.

Ну и Макконел — не аналитик, так сказать, в чистом виде, ему то, что не относится непосредственно к модели качества и метрикам, которые отражаются в коде, видимо, неинтересно.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity