согласен с sukhanchik и gl00mie
и хочу добавить, что ветка плавно скатывается в то, что уже обсуждалось
Cтоит ли программистов огораживать консультантами от пользователей?
Про консультантский подход
Цитата:
Сообщение от
Evgeniy2020
В 2007 ом были документы протоколы изменения системы. но с тех пор их никто не вел и они стали неактуальными. в них что то есть но положится на них проблематично.
В аксапте есть контроль версий.
В аксапте есть создание проекта, который содержит изменения в слоях.
но эти инструменты действуют на уровне кода, а не на уровне абстракций.
нет инструментов, которые действуют на уровне абстракций для бизнес-аналитиков.
(разве что проекты, но это жалкое подобие левой руки)
поэтому либо писать вручную такие документы, либо таки делать маппинг от кода к асбтракциям (в первый раз тоже вручную и обязательно работая совместно с пользователями). Когда сделаете маппинг, то можно будет воспользоваться существующими инструментами Аксапты.
Цитата:
Сообщение от
Evgeniy2020
На текущий момент ни в консалтинговой компании на которой завязан переход, ни в самой компании А нет людей которые СХОДУ могли бы сказать, что является доработкой а что теперь есть в новом стандарте АХ 2009 в качестве аналогов.
попросили составить документ анализа системы...
А кого попросили, если людей соответствующей квалификации нет?
Наймите правильных людей.
Цитата:
Сообщение от
Evgeniy2020
И теперь вопрос как действительно и эффективно избавится от хлама, написанного за 4 года и перейти и задействовать новый стандарт АХ 2009 (стандартную функциональность)
1. Узнать у пользователей
точки входа (какие меню, какие кнопки нажимают, какие параметры выбирают)
2. Дополнительно выявить точки в автоматически выполняемых периодических заданиях. Скорее всего это Пакеты (batch), но может быть и внутри SQL, а также могут запускаться по шедулеру из самой винды.
3. Настройки узнать в настройках.
4. Используя перекрестные ссылки, начиная от точке входа отследить какой код гарантировано не используется, какой код может использоваться, какой код гарантировано используется.
5. Провести дополнительный анализ для кода, который не используется: перекрестые ссылки могут не поймать некоторые связи, если код написан через хитрую жопу - например, для выражения myTable.(fieldnum) в перекрестных ссылках не будет отображено, что таблица и поле используются
6. (опицонально) провести маппинг объектов AOT в абстракции с нужной степенью детализации (вручную. другого способа нет). Пример грубого маппинга, все объекты семейства LedgerJournalEngine отвечают за
разноску журналов. Пример более точного маппинга, класс LedgerJournalEngine_Payment и его потомки отвечают за
разноску журнала платежей. Еще пример, LedgerJournalEngine_VendPayment - отвечает за
разноску журнала платежей поставщику.
Обратите внимание, что жирным выделены точки входа, которые указали пользователи. Если ваши абстракции будут (более-менее) совпадать с точками входа, то анализ и дальнейшая работа намного облегчится.
Также обратите внимание, что объекты могут маппироваться на несколько абстракций. Например, тот же журнал платежей может маппироваться и на графики платежей, и на прогноз движения денежных средств, и на векселя, и на штрафные санкции за просрочку платежа, и на НДС с авансовых платежей, и на счета-фактуры и т.д. Т.е. если начнете делать такой маппинг, то начните с грубого, но готовьтесь постоянно уточнять его, чтобы получить нужную для принятия решений детализацию.
7. провести анализ
8. принять решение о выкидывании неиспользуемого кода.
Причем легче всего будут даваться решения по самым неважным и нетрудоемким для переноса участкам кода. Например, какие-нибудь копии таблиц, которые делались для каких-нибудь проверок, но так и забыты. Или какие-нибудь копии классов/Job'ов.
А труднее всего будут даваться решения по действительно важным вещам. Здесь уже приводился пример появившейся в ax2009 разноски по складам. Если у вас такая штука уже реализована, то скорее всего, идеология работы не совпадает с тем, что появилось в ax2009. Кроме того, чтобы перейти на штатную в ax2009 скорее всего придется перелопатить кучу кода. Вопрос "оставить вашу разноску или вернуться к стандартной?" чертовски сложен и неоднозначен.
Цитата:
Сообщение от
Evgeniy2020
каков эффективный workflow для этого перехода и чтобы не переплачивать?
постоянно вести документацию и описания во время проекта.
если документация не велась, то придется перелопачивать хотя бы один раз.
=================
(опционально)
ваш изначальный вопрос сводится к следующему:
"как построить маппинг из объектов в абстракции и как его отобразить понятном для человека-непрограммиста в виде"
маячок:
маппинг => онтологии,
модель онтологий,
еще
отображение онтологий => редакторы онтологий
но только поверьте человеку, который к этой задаче для Аксапты подступал уже несколько раз: построение
полезных для использования онтологий - более трудоемкая задача, нежели задача построения полезного для вас маппинга вручную.
поэтому просто опросите пользователей, узнайте точки входа и сделайте анализ, не надеясь на магическую красную кнопку. "серебряной пули нет".
основная проблема: онтология содержит огромное количество чисто технических аспектов, которые неинтересны для принятия решений, но их приходится включать чтобы получить правильную онтологию. Причем эти технические аспекты появляются как при автоматическом построении онтологий, так и при ручном. Здесь уже приводились примеры - метод округления сумм, диалоги, системные окна, процедуры печати, процедуры контроля окон и т.п.