Описание алгоритмов, бизнес-процессов

ferzmikk
Дата: 09.08.2017 19:20:52
Здравствуйте!

Возьмем к примеру, что в компании присутствует проект как бюджетирование. Особенность этого проекта заключается в том, что логика, аналитика и бизнес процессы сложная, со временем дорабатывается, следовательно, дорабатывается код для каждого проекта исходя предоставленных ТЗ. Но за долгое время прописанный код получается очень сложным. Со временем мощные инструкции устаревают и что кропотливо дополнять их, удалять устаревшую информацию. И для какой то доработки забыли ввести корректировку в инструкции. Читать отдельно ТЗ очень трудоемко, да еще учитывать эволюцию автоматизации. Текстовые инструкции да еще написанные программистами очень тяжело читать.

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

Какие существуют подобные технологии?
ShSerge
Дата: 09.08.2017 20:46:07
Я пишу бизнес-процессы на TeamCenter фирмы Siemens.
Признась, что такое менеджеры и бизнес-аналитики не очень понимаю. У нас есть клининг-менеджеры, но это - сторонняя фирма.
Dima T
Дата: 09.08.2017 21:01:52
Надо не ТЗ писать на каждый чих, а вникнуть в предметную область и просто понять что надо конечному юзеру, тогда вся сложность чтения ТЗ исчезнет и появится нужный результат.
ShSerge
Дата: 09.08.2017 21:30:54
Dima T,

Несколько другое. Например, бизнес-процессом (workflow) является, скажем так, утвержение некоторого документа, который вы составили. То есть, этот должен утвердить, тот должен, и т.д. . На каждом шаге документ может быть отклонён и завёрнут в какую-то точку, и может появиться ещё какой-нибудь подписант, в зависимости от контекста.
Ну да, блок-схема утверждения рисуется. После проходения документу присваивается статус "утверждено".
ferzmikk
Дата: 09.08.2017 21:56:58
Слышал, что есть программа Business Studio. Она решает такую проблему или это другое?
Dima T
Дата: 09.08.2017 22:00:29
ShSerge
Dima T,

Несколько другое. Например, бизнес-процессом (workflow) является, скажем так, утвержение некоторого документа, который вы составили. То есть, этот должен утвердить, тот должен, и т.д. . На каждом шаге документ может быть отклонён и завёрнут в какую-то точку, и может появиться ещё какой-нибудь подписант, в зависимости от контекста.
Ну да, блок-схема утверждения рисуется. После проходения документу присваивается статус "утверждено".

Ерунда все это, бюрократия. Если мне важен документ, то я заранее согласую его с остальными подписантами. Подпись это формальность.
ShSerge
Дата: 09.08.2017 22:13:48
Dima T
...Ерунда все это, бюрократия. Если мне важен документ, то я заранее согласую его с остальными подписантами. Подпись это формальность.

А если ты работаешь на заводе, а документы - чертежи, которые твой отдел десятками за день штампует. А нужно согласовать с металлургами, нормоконтролем и т.д.?
Basil A. Sidorov
Дата: 10.08.2017 00:53:48
Dima T
Подпись это формальность.
Да-да, а административная и уголовная ответственность это такие слова в одноимённых талмудах.
dimonz80
Дата: 10.08.2017 07:08:38
ferzmikk
Здравствуйте!

Возьмем к примеру, что в компании присутствует проект как бюджетирование. Особенность этого проекта заключается в том, что логика, аналитика и бизнес процессы сложная, со временем дорабатывается, следовательно, дорабатывается код для каждого проекта исходя предоставленных ТЗ. Но за долгое время прописанный код получается очень сложным. Со временем мощные инструкции устаревают и что кропотливо дополнять их, удалять устаревшую информацию. И для какой то доработки забыли ввести корректировку в инструкции. Читать отдельно ТЗ очень трудоемко, да еще учитывать эволюцию автоматизации. Текстовые инструкции да еще написанные программистами очень тяжело читать.

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

Какие существуют подобные технологии?


BPMN.
exp98
Дата: 14.08.2017 13:19:58
ferzmikk, не гонитесь за необъятным, в этом деле всё запущено.
Чё-то для явы такое есть, с прикручиванием к проге на яве, но всё это отдельная работа.
Главный и с бородой вопрос, я думаю, как автоматизировать написание проги исходя из блок-схемы.

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

Потребители схемы. Красивого универсального для юзеров всех уровней документа на боле-мене громоздкий проект быть не может. Соответственно нужно несколько типов донесения инфы. Один аналитик/рограммист "ниасилит". Комментировать схемы, чтобы "на пальцах" объяснить рабочие процессы, тоже надо уметь. "Профессиональные" тех.писатели так же плохо понимают программистов, как и рабочие процессы (читали хелп ексела по статистике?)

BPMN/BPEL - красиво, но ничто не ново под луной. С первых же примеров видно смесь ИДЕФов и "ручейковых" + события ЮМЛов, т.е. понимания их достаточно. Да, конечно, должен быть закон, использовать только конкретные элементы. Кричать, мол, это корпоративный стандарт, недостаточно: придёт другой (хоть бы и директор) и скажет, что стандарт д.б. другой ... или ну его нафик ...

Один раз нарисовать что-то (ТЗ, схему, пргу, доку ...) красиво могут все. Но кто будет подддерживать изменения, и кто и что будет заставлять их это делать?
Есть такой метод изменений в проге как "заплатка". Со временем растут заплатка на заплатке, а кто захочет реорганизовывать прогу, чтоб было красиво? Точно так же и со схемами. Рисовальщики даже более ленивы, и со временем формальная схема станет мало понятной.