|
![]() |
#1 |
Участник
|
Цитата:
![]() Цитата:
А что вы называете "понятным бизнес-аналитику видом"? Цитата:
Всегда было просто. И сейчас также. Цитата:
и сравнивайте со старым. (специально скриншот снял со старой версии ax3.0 - всегда эти инструменты были) Цитата:
Цитата:
После разгромного митинга вам урезали интернет? Забанили в гугле? Выгоняют с работы? Цитата:
пользуйтесь тегами. Цитата:
Что не устраивает в существующем представлении? Что то у меня возникает нехорошее чувство, что вы не знаете о переключателе "показывать все слои". юзайте его. и никакого цвета не нужно. так надо работать: а так переключатель установлен по умолчанию: если вам нужно получить список объектов в табличном виде для дальнейшей обработки, то юзайте замечательную форму "Объекты приложения". Включайте фильтры - и вперед. Если хочется раскраски цветом, то выгрузите отфильтрованные объекты в excel и раскрасьте. Обратите также внимание на поля "Автор модификации" и "Дата модификации". Даю маячок: по этим полям тоже можно включить фильтры и сортировку(!) Цитата:
пожалуйста определите понятие "используемого функционала". я еще понимаю как получить "включенный функционал" - при помощи конфигурационных ключей. я еще понимаю как получить "разрешенный функционал" - при помощи прав доступа. Но как получить "используемый"? Я правильно понимаю, что ваши бизнес-аналитики не знают что именно используют ваши пользователи? Если да, то совершенно согласен с определением "разгромный митинг". Под жопу таких аналитиков и гнать поганой метлой. Цитата:
Значит ли это "никогда не открываемый"? А если пользователь из любопытства тыкнул и открыл? Тогда он перестает быть "не используемым"? Значит ли это "выключенный" или "запрещенный правами доступа"? Правильно ли я понимаю, что вы помните о пакетных заданиях, которые могут выполняться автоматически? (пользователь никогда их не открывает, но они выполняются) Итак, что такое "не используемый"? Цитата:
Уж пользователи то с огромным удовольствием расскажут чем они пользуются часто. но если вы таки хотите автоматически, то для таблиц есть Журнал трассировки операторов SQL. Включите его. Далее анализируйте стеки. (снова совершенно сознательно привел скриншот старой версии) Но предупреждаю: журнал трассировки здорово нагрузит SQL сервер и здорово затормозит работу пользователей. Думаю, что простая и регулярная работа с пользователями даст гораздо более полезный результат, и гораздо эффективнее. а для кода в ax3.0 есть макросы #ProfileBegin, #ProfileEnd. В более старших версиях есть еще и Trace Parser. Но, если включать их на всем функционале, они точно убьют вашу систему. Если же вы хотите узнать самый часто выполняемый код в системе, то это запрос основной валюты в настройках компании, чтобы узнать число десятичных знаков. первая сотня самых часто выполняемых методов - это очень системные и внутренние методы, не имеющие ничего общего с задачами пользователей. (например, узнать число знаков после запятой в основной валюте) Так что такое "часто используемый"? Цитата:
так и скажите "наши бизнес-аналитики ни хрена не знают о наших процессах и о задачах/действиях наших пользователей". Вы сначала расскажите что вас не устраивает в УЖЕ существующих инструментах? И может расскажете что вам мешает просто и надежно опросить пользователей? |
|
|
За это сообщение автора поблагодарили: Lemming (7), sukhanchik (8), lev (4), IvanS (1), player (1). |
![]() |
#2 |
Модератор
|
Цитата:
Допустим, выводимая там информация точна. А дальше что? "Бизнес-аналитикам" это явно не поможет Цитата:
Под жопу таких аналитиков и гнать поганой метлой.
![]()
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#3 |
Участник
|
Это то, что в 2009-й появилось? Но ведь это не статистика никакая - там показывается максимум то, какие объекты вообще использовались за день, а как часто они используются в течение дня, из этих логов не узнать...
|
|
![]() |
#4 |
Модератор
|
Зачем гадать, если можно запустить отчет? Хинт - это виртуалка, последний раз перезапускалась 8/27
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: Evgeniy2020 (1). |
![]() |
#5 |
Участник
|
А я вовсе не гадаю - я сужу по коду сбора этой "статистики" - см. \Data Dictionary\Tables\SysUtilElementsLog\Methods\persistRegisteredUsagesServer. Т.н. "разы" использования в отчете - это на самом деле количество различных дат, в которые было залогировано использование той или иной формы/отчета, а вовсе не количество раз, которое они открывались.
|
|
|
За это сообщение автора поблагодарили: Vadik (1). |
![]() |
#6 |
Участник
|
Спасибо за развернутые ответы,
свои ответы и концепты подготовлю чуть позже. так как возможно что то придется нарисовать возможно прототипное. надо еще на ММАС 2010 сходить успеть пока время есть. чуть позже объясню и отвечу. 2 Lemming прежде чем лепить минусы )) надо хоть как то аргументировать что конкретно там вы не считаете нужным. здоровая критика приветствуется а молчаливые оценки полезной нагрузки не несут, лишь говрят о субъективности восприятия. а оно действительно у всех разное и не надо думать что именно у вас оно самое правильное, хотя бы аргумент привели бы. Спасибо. ![]() просто я не достаточно еще раскрыл тему и хотел бы показать на рисунках прототипах, как функциональность можно видеть глазами бизнес аналитика. у нас работают прекрасные бизнес аналитики. но знать что такое АОТ и что такое SYS GLS VAR CUS и ветки АОТ хорошему аналитику вовсе не обязательно. достаточно знать что есть стандарт, кастомизация или свое кустарное с нуля. я думаю ничего страшного что наши аналитики даже не знают что такое АОТ, они и так отвечают еще за две системы. программеры да те как раз срощены с АОТ и у хорошего программиста за годы 80% АОТ закэшировано в голове. и на вопрос скажи а как реализовано то или то, он ответит быстро аналитику, а уж если в кэш не попали или нужно обновить, то программер посмотрит в АОТ и через время распарсит и выдаст как это реализовано, является ли это стандартом, кастомизацией или полной кустарной разработкой. поэтому сейчас я и вижу как программист является тем самым медиумом который в голове закешировал 80% АОТ и когда его спрашивают бизнес аналитики а как это у нас реализовано в системе программист парсит все это в голове и выдает что реализовано за счет кастомизации такой то или написано с нуля (кустарно). получается без знания Основы реляционных баз данных, принципы ООП, слоенная технология, структура АОТ, классы формы таблицы, профессиональный бизнес аналитик не сможет без помощи медиума (программиста) ответить на множество своих вопросов. В то же самое время программисты реализуют эволюционные измнения в системе или отвечают на вопрос как это реализовано, за счет кэширования АОТ в голове и понимания выше перечисленных требований (парсить все). НО настоящими эволюционерами являются бизнес аналитики и консультанты, так именно они являются посредниками между пользователями потребностями требованиями и программистами, именно консультанты и бизнес аналитики описывают те изменения которые необходимо внести в систему и ставят задачи перед программистами те в свои очередь проводят эти изменения и они отражаются в АОТ, и потом кэшируют обновленный АОТ в голову (это в шутку конечно сказано, прошу не воспринимать все слишком прямо). по поводу начальных терминов для концептов Стандарт (функциональность в SYS GLS) Кастомизация (функциональность расширенная в слоях VAR CUS USR но изначально присутствующая в SYS GLS) Кустарщина (функциональность полностью рожденная в слоях VAR CUS USR) итак немного об помощи системе эволюционирования приблизительный аналог стандарт уже в ДНК системы кастомизация расширение ДНК системы кандидат на постоянное включение в ДНК кустарщина эволюционное изменение требующее проверки времени (возмжно будущий кандидат на включение в ДНК системы или потенциальный генетический мусор) принцип эволюционирования системы, подтвержденные временем элементы попадают в днк, отмирающий генетический мусор (в резлультате кривых разработок, или внешних изменений законодатльства, или есть лучше образцы) должен умирать и удалятся из системы в утиль. ладно прощу прощения чуть позже опишу и мжет попробую нарисовать прототипы как можно видеть АОТ глазами бизнес аналитиков и не программистов. и to Lemming попрощу не добавлять оценки отрицательные без комментариев. такие оценки ьез комментариев пользы не несут, только субъективность обнажают. и вообще лезут всякие леминги в обсуждение прототипов. вообще не пониамаю лезть в обсуждение прототипов и чо там ставить без комента. попрошу лично Lemming ответить за что он поставил свою оценку в обсуждении прототипа слоя преставления информации АОТ для бизнес аналитиков Последний раз редактировалось Evgeniy2020; 28.08.2010 в 10:42. |
|
![]() |
#7 |
Axapta
|
Цитата:
|
|
![]() |
#8 |
Administrator
|
Цитата:
![]() Пример. Я стер код разноски накладной и вставил одну строку вызова своего класса (созданного в VAR), который делает "разноску по sukhanchik". Это кустарщина? А если я весь код своего класса поместил в тот метод, в котором я все стер? Это уже кастомизация? А для конечного пользователя - разницы нет - функционал работает не по стандарту. Второй пример. До 2009 RU3 в АХ существовала распространенная модификация при внедрении - называемой "разноска по складу". Это кустарщина? (есть объекты, относящиеся к этой модификации, которые созданы в VAR или выше). Или кастомизация ? (т.к. "разноска" как термин уже существует в стандартной функциональности, да и "склад" как термин существует). Или все-таки кустарщина - т.к. такого функционала ранее не было? Тогда все кастомизации=кустарщине.
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#9 |
Участник
|
Цитата:
Сообщение от Evgeniy2020
![]() я думаю ничего страшного что наши аналитики даже не знают что такое АОТ, они и так отвечают еще за две системы.
программеры да те как раз срощены с АОТ и у хорошего программиста за годы 80% АОТ закэшировано в голове. и на вопрос скажи а как реализовано то или то, он ответит быстро аналитику, а уж если в кэш не попали или нужно обновить, то программер посмотрит в АОТ и через время распарсит и выдаст как это реализовано, является ли это стандартом, кастомизацией или полной кустарной разработкой. У разработчиков какая-то часть "АОТа" закэширована потому, что они либо по каким-то причинам долго и упорно ковырялись в соотв. коде - может, косяк какой исправляли или еще что, либо сами делали соотв. модификации (особенно если это не бантик, а какой-нить значимый кусок функционала). Аналогично, у аналитиков тоже должны быть закэшированы какие-то участки функционала, потому что они ковыряли, как оно работает в стандарте, и потом писали ТЗ на модификации. Цитата:
Сообщение от Evgeniy2020
![]() НО настоящими эволюционерами являются бизнес аналитики и консультанты, так именно они являются посредниками между пользователями потребностями требованиями и программистами, именно консультанты и бизнес аналитики описывают те изменения которые необходимо внести в систему и ставят задачи перед программистами те в свои очередь проводят эти изменения
|
|
|
За это сообщение автора поблагодарили: Evgeniy2020 (1). |
![]() |
#10 |
Участник
|
Спасибо огромное gl00mie
он больше всех приблизился именно к тому о чем я начал речь, и что описываб в этой ветке. я тут вставлю именно то что буквально в яблочко gl00mie писал: не в АОТ, а в некий репозитарий по модификациям, где собраны ТЗ на доработки Опять же, все так, только прежде чем ставить задачи по модификации системы, нужно иметь хорошее представление о том, что уже есть в стандартном и кастомизированном функционале, как оно работает, для чего задумано - может, что-то можно настройками решить или пользователей чему-нить научить, чтоб в коде ничего править не пришлось. И вопрос перехода на новую версию во многом упирается в то, чтобы 1) знать стандартный функционал прежней версии, 2) знать функционал, реализованный в модификациях и "кустарщине" (пользуясь вашей терминологией) и 3) знать стандартный функционал новой версии - и уметь в голове это все совмещать и крутить по-всякому, чтобы в результате понять, от каких доработок отказаться в пользу нового стандартного функционала, а какие - перенести на новую версию, да еще как их изменить, чтобы они в новый стандартный функционал вписались. Тут никакие сторонние медиумы не помогут. ситуация на практике действительно такова что нет тех бизнес аналитиков которые создавали систему. и все остальное буквально именно то о чем я говорил по бизнес аналитиков и масштабности версий ах дальше. что скоро потребуется вместо 500 квтч ч мозга 2 млн квтч мозга чтобы держать в голове 2 талмуда стандарта новой версии 1 талмуд предыдущей, еще закэширифанный кэш модиф, чтобы родить правильное изменение. это что я называю ТСС total cost of change что при возрастании масштабов системы он будет расти чуть ли не экспонициально (напоминая кривую обучения) и второй параметр TCO total cost of ownership что при таких случаях оперировать системой в отсутствии авторов и начальных бизнес аналитиков приходится порой привлекать конасалтинговые компании и это тоже временно, так как после проведения работ многое закэшировано в голове представителя консалтинговой компании. и тогда постепенно TCO растет внушительно. почему зачастую компании боятся потерять программиста (который 6 лет) работал на одном месте и закэшировал 80% АОТ и аналитика (консультанта) который закэшировал доработки. знакомая ситуация? )) думаю знакомая многим из за того что ТСО и ТСС неимоверно возрастут при потере этих лиц. легче доплатить спецам чтбы они еще остались дальше чем встретится с рисками и резким возрастанием ТСО и ТСС. я сегодня проанализировал дальше все. и честно говоря прощу прощения но первым делом 2 Lemming пошел нах и больше чтоб не учавствовал в обсуждениях прототипов где я автор. ХОЧУ ПО НАСТОЯЩЕМУ ЗАКРЫТЬ ЭТУ ВЕТКУ. и если есть возможность удалить мои сообщения вообще в этой ветке. ПРОСТО УДАЛИТЬ ЭТУ ВЕТКУ. 2 oip для вас я постараюсь выполнить обещание но уже без придания публичной огласки, готов позже сделать если необходимо через личку. конечно с некоторыми в закрытом виде я бы продолжил бы тему. дело в том что я увидел перспективность направления. особенно благодарность gl00mie Vadik Suhanchik Mazzy. спасибо что не поленились ответить на казалось бы абсурдную тему. Последний раз редактировалось Vadik; 29.08.2010 в 21:35. Причина: оскорбления |
|
|
За это сообщение автора поблагодарили: Vadik (-5), oip (-11). |
Теги |
диаграмма классов, модель данных, crm2011 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|