спасибо, да это SDD. Но как я понял основная его тема - хранение спецификаций в md файлах, а чтобы в специализированной базе данных - такого мои агенты не находят. Альтернатива - хранение спецификаций в текстах Задач, подзадач и эпиков в трекерах - уже чуть лучше, можно и согласовать, но все равно это воздушный шар - вид сверху. сложно визуализировать и понять разрастающееся приложение. Эксперимент показал - что фактически перед нами аналитик-программист, а не просто программист. Я такого не ожидал. Он сначала выполняет роль аналитика и работает в контуре моделирования в erp-tools, а потом начинает кодировать в cursor. Про то, что под силу только средние по сложности - не совсем соглашусь. программа создавалась для управления доработки ERP систем - там большое число функций-пользовательских действий это входное условие. Держать контроль над несколькими сотнями таблиц и работы с ними - это стартовая задача. Само приложение erp-tools содержит около 50 Таблиц - но оно довольно сложное в плане пользовательских действий. не думаю что с его реализацией будут проблемы по этой методологией.
Ну это фактически должностная инструкция. Не написано, кстати, что нужно перчатки надеть перед этим. Зачем в описании ERP системы так подробно описывать деятельность за пределами ERP и конечно это не должностная инструкция - вы сами пишите, что у вас только 2-3 интервью с участниками. И второе - самой работе в 1С совсем не уделено место. Формирует акт расхождение - это так документ называется? "Выявлен бракованный товар" - "товар перемещен на склад брака" - это действие в 1С или действия в материальном мире? точно так просто? никто не должен подписать у начальника документ о браке? Мне кажется в предпроектном исследовании такие процессы невозможно охватить вниманием. И при перемещении на склад брака - есть ли подробности - ордерный он, ячеистый, что там с сериями происходит
Для всех переносимых справочников и документов начальных остатков создается специализированный дополнительный документ "Загрузка начальных данных", в котором можно контролировать фактическую приемку от заказчика итоговых списков справочников и документов. При этом есть возможность использовать разные шаблоны загрузки. Например, Справочник Контрагенты имеет несколько шаблонов "Клиенты, поставщики, прочие", которые обуславливают заполнение разного набора реквизитов. Плюс каждая "порция" загружается по своему плану, так как к началу ОПЭ как правило готовы только остатки ТМЦ на складах и взаиморасчеты. В прошлой статье я раскрыл имя программы erp-tools, в you-tube есть кое-что про загрузку начальных данных этой методологией. Я полностью исключил использование программистов и КД из процесса, заменив их программным роботом и аналитики как раз эти реестры справочников и их шаблонов и ведут.
Спасибо за вопрос. Безусловно - актуальность и оптимизация фактических справочников вопрос максимально важный и дубликаты и неаккуратное ведение НСИ могут поломать даже идеальную модель. Если говорить о прикладном использовании Методологии, то мы храним "Статические справочники" (структура предприятия, виды номенклатуры) непосредственно в "Объектах метаданных системы" и обеспечиваем явное согласование их заказчиком до старта ОПЭ. То есть в принципе в этом смысле данные НСИ являются часть Методологии. Динамические справочники (номенклатура, контрагенты) в этом контексте остаются за рамками методологии.
спасибо, да это SDD. Но как я понял основная его тема - хранение спецификаций в md файлах, а чтобы в специализированной базе данных - такого мои агенты не находят. Альтернатива - хранение спецификаций в текстах Задач, подзадач и эпиков в трекерах - уже чуть лучше, можно и согласовать, но все равно это воздушный шар - вид сверху. сложно визуализировать и понять разрастающееся приложение. Эксперимент показал - что фактически перед нами аналитик-программист, а не просто программист. Я такого не ожидал. Он сначала выполняет роль аналитика и работает в контуре моделирования в erp-tools, а потом начинает кодировать в cursor. Про то, что под силу только средние по сложности - не совсем соглашусь. программа создавалась для управления доработки ERP систем - там большое число функций-пользовательских действий это входное условие. Держать контроль над несколькими сотнями таблиц и работы с ними - это стартовая задача. Само приложение erp-tools содержит около 50 Таблиц - но оно довольно сложное в плане пользовательских действий. не думаю что с его реализацией будут проблемы по этой методологией.
А что такое Имаго? погуглил - чтот-то из жизни насекомых
Ну это фактически должностная инструкция. Не написано, кстати, что нужно перчатки надеть перед этим. Зачем в описании ERP системы так подробно описывать деятельность за пределами ERP и конечно это не должностная инструкция - вы сами пишите, что у вас только 2-3 интервью с участниками. И второе - самой работе в 1С совсем не уделено место. Формирует акт расхождение - это так документ называется? "Выявлен бракованный товар" - "товар перемещен на склад брака" - это действие в 1С или действия в материальном мире? точно так просто? никто не должен подписать у начальника документ о браке? Мне кажется в предпроектном исследовании такие процессы невозможно охватить вниманием. И при перемещении на склад брака - есть ли подробности - ордерный он, ячеистый, что там с сериями происходит
Для всех переносимых справочников и документов начальных остатков создается специализированный дополнительный документ "Загрузка начальных данных", в котором можно контролировать фактическую приемку от заказчика итоговых списков справочников и документов. При этом есть возможность использовать разные шаблоны загрузки. Например, Справочник Контрагенты имеет несколько шаблонов "Клиенты, поставщики, прочие", которые обуславливают заполнение разного набора реквизитов. Плюс каждая "порция" загружается по своему плану, так как к началу ОПЭ как правило готовы только остатки ТМЦ на складах и взаиморасчеты. В прошлой статье я раскрыл имя программы erp-tools, в you-tube есть кое-что про загрузку начальных данных этой методологией. Я полностью исключил использование программистов и КД из процесса, заменив их программным роботом и аналитики как раз эти реестры справочников и их шаблонов и ведут.
Спасибо за вопрос. Безусловно - актуальность и оптимизация фактических справочников вопрос максимально важный и дубликаты и неаккуратное ведение НСИ могут поломать даже идеальную модель. Если говорить о прикладном использовании Методологии, то мы храним "Статические справочники" (структура предприятия, виды номенклатуры) непосредственно в "Объектах метаданных системы" и обеспечиваем явное согласование их заказчиком до старта ОПЭ. То есть в принципе в этом смысле данные НСИ являются часть Методологии. Динамические справочники (номенклатура, контрагенты) в этом контексте остаются за рамками методологии.