Как стать автором
Обновить
25
Карма
0
Рейтинг
Наталья Желнова @enotinka

Пользователь

Что такое BPMS

Отвечу я, как бывший главный аналитик проекта, который был признан "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 тоже разное.

Основы Git

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

Нефункциональные требования к программному обеспечению. Часть 1

Хороший вопрос.
Я думаю, что нынешним летом (но уже ближе к августу) я ее напишу.

Откуда берутся бизнес-аналитики?

«Быстро печатать» — это несомненное преимущество для бизнес-аналитика, равно как и моделировать «во всяких интересных нотациях».

Я удивляюсь, что подобные статьи могут появляться в эпоху, когда существует множество профессиональных ресурсов для бизнес- и системных аналитиков. Хотя бы:
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.

Нефункциональные требования к программному обеспечению. Часть 1

Журнал запросов на выполнение работ — на мой взгляд, не самый удачный перевод. Лучше, мне кажется, журнал запросов на изменение.
У «Русской редакции когда-то была мода ставить в информацию об издании фамилию редактора. По крайней мере, свою я там видела, когда редактировала книги по SQL Server (администрирование и разработка). Иногда ставили фамилии переводчиков (по крайней мере я на этом настаивала, когда работала вместе с людьми, которые начинали свой путь в программировании с разработки движков для баз данных).
Теперь эта мода у „Русской редакции“ прошла — они переводят книги силами компании Логрус, занимающейся локализацией разных программных продуктов, в том числе и Microsoft. Работу переводчиков в Логрусе часто выполняют студенты. Что касается редактуры — похоже, что от нее и вовсе отказались.

Нефункциональные требования к программному обеспечению. Часть 1

Да, но разница в том, что бизнес-правило может диктовать, как именно должен выполняться сценарий. Если бы бизнес-правила не существовало, этот сценарий мог бы быть реализован 10-20 различными вариантами. А если оно есть — то только одним.

Нефункциональные требования к программному обеспечению. Часть 1

Во второй части будет.

Нефункциональные требования к программному обеспечению. Часть 1

Это смесь того, «что» и «как». По отношению к сценарию отгрузки товара — это как должна выполняться операция.

Нефункциональные требования к программному обеспечению. Часть 1

Да, собственно, как их классифицировать или делить на категории — это не столь уж принципиально.
Важнее — как их определять, и на что они влияют в системе.

Нефункциональные требования к программному обеспечению. Часть 1

Да, в общем, многое в требованиях является сущностью реального мира. И бизнес-правила, как один из типов ограничений — тоже. И в зависимости от наличия автоматизации и способа автоматизации некоторые бизнес-правила могут меняться.
Считать их разновидностью ограничений, диктующих нам, как реализовывать ту или иную функцию или группу функций — вполне корректно. Если предположить, что водораздел между функциональными и нефункциональными требованиями проходит по линии «что надо сделать (функциональные) — как надо сделать *нефункциональные)», то получится, что ограничения как раз попадают в нефункциональные требования.

Нефункциональные требования к программному обеспечению. Часть 1

Вигерс Карл, Разработка требований к программному обеспечению, Москва, «Русская Редакция», Подписано в печать 03.12.03
Глава 1 стр. 8
Знаменитый рисунок, проводящий границу между функциональными и нефункциональными требованиями:

image

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

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

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

Нефункциональные требования к программному обеспечению. Часть 1

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

Нефункциональные требования к программному обеспечению. Часть 1

Я думаю, что мы должны в первую очередь определиться с терминологией.
Нефункциональные требования — это требования, которые определяют не функции, а характеристики системы: ее производительность, надежность, доступность, масштабируемость и ряд других параметров (здесь перечислены характеристики качества, но, как уже сказано в статье, есть и другие виды нефункциональных требований). Требование к времени отклика вашего приложения — это тоже нефункциональное требование («производная» от производительности). Думаю, пользователям вряд ли понравится, если реакции системы они будут ждать 4 минуты после нажатия на кнопку интерфейса. Но в течение 2-3 секунд они могут подождать. Это самый простой пример.
Нефункциональные требования самым непосредственным образом определяют архитектуру разрабатываемого приложения, поэтому определять их очень важно, хотя многие предпочитают этого не делать, полагаясь на то, что hardware и технологии, с которыми они работают, уже обладает какими-то характеристиками качества — следовательно, определенное качество уже можно гарантировать. Отсутствие должного внимания, уделяемого нефункциональным требованиям, часто приводило к серьезным последствиям — от перепроектирования системы до полного провала проекта.
Что касается «основных» и «не основных» требований — приоритеты задаются для всех требований, как функциональных, так и нефункциональных. Категория требований и важность — это просто две разные вещи. Как функциональные, так и нефункциональные требования могут иметь как высокий, так и низкий приоритет.

Метрики в проектах по разработке ПО

Так зачем тогда метрики?
Хороший вопрос. Мне кажется, первая фраза уже содержит ответ на него: чтобы понимать состояние проекта.
И сотни метрик, как мне кажется, не нужны. Нужны только те метрики, которые помогут нам ответить на вопросы:
1. Сколько денег мы должны иметь в распоряжении, чтобы они не закончились в самый неожиданный момент (нижняя и верхняя граница)?
2. Сколько людей и с какой квалификацией мы должны привлекать к работам, в какие сроки?
3. Каково общее состояние проекта, сколько работы сделано, сколько еще осталось?
Ответив на эти вопросы, мы получим искомое.

Метрики в проектах по разработке ПО

Да, спасибо.

Идеи для проектов: UI сайта знакомств, ч. I

Теперь я буду знать, кто такие undev!

Метрики в проектах по разработке ПО

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

Метрики в проектах по разработке ПО

Да, спасибо за замечание — считается отклонение сумм, конечно же.
1

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирована
Активность