АОТ для бизнес аналитиков

[AlGol]

Цитата:

Сообщение от sukhanchik

А по факту получается - что для автоматизации чего-то - сначала нужен ручной труд.

Поддерживаю - этот ручной труд простонародно "автоматизацией" и называется. Т.е. болтики и винтики надо вкрутить руками в определенное место чтобы машина сама ездить начала.

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

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

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

Когда я начинал работать с Аксаптой, в моем ближайшем окружении было достаточно попыток описать ее логику с помощью диаграмм и пр. Но они были полезны, насколько я сейчас вижу, для понятия общей логики системы, взаимодействия модулей в глобальном масштабе. Ньюансы работы всегда разбирались по коду.
Например, нужно было всем объяснять что для разноски проводки ГК сначала создается журнал. После разноски - журнал может остаться может быть стерт, но он уже не влияет на фин результаты.

[Evgeniy2020]

Цитата:

с описанием функциональности классов, методов и пр.
Т.е. к каждому классу привязано некое описание его роли в системе. Такая карточка класса. Раскрывая какой класс вызывается определенным пунктом меню, мы типа раскрываем какая функциональность будет работать.
Описав каждый метод в классе, можно типа раскрыть логику работы класса более подробно.

Нет нет нет, нельзя объять необъятное ))
если мы систему до такого уровня представим боюсь что юзабилти упадет до нуля.
нужно будет опять 2 млн квтч в мозгу чтобы ворочать таким муравейником.

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

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



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

можно добавить служебную кнопку в панели инструментов, сообщить о сложностях, и пользователь нажимая кнопку в окошке пишет коммент на форму, или там на окно вызова чего то.

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