AXForum  
Вернуться   AXForum > Рынок > Методология внедрения
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 16.09.2009, 15:11   #1  
Lanai is offline
Lanai
Участник
 
35 / 29 (1) +++
Регистрация: 09.08.2005
"Правильность" построения системы
Добрый день!
Вопрос какой-то филосовский. Не судите строго.

Есть ли какие-либо пастулаты, по которым можно определить "правильно ли" сконструирована (набор аналитик, разбиение плана счетов и пр.) система (разговор про Аксапту)? И что означает "правильно" (довольно руководство и все получают то что хотели или же это когда система сконструирована в соответствии с заложенными в неё этими "правильными" пастулатами?

Задайте, плз, уточняющие вопросы, если я плохо формулирую. Самому тяжело.

Ну и такой вопрос (как бы пример "правильного" пастулата): имеет ли место быть такое правило и верно ли это: Если для построения отчета программистам требуется информация одновременно и по модульным проводкам и по проводкам главной книги - то это "неправильно" и свидетельствует о том что система сконструирована "неправильно" или в любом случае что-то не продумано и "не правильно" делать такие отчеты ?

Как-то так... Может быть не понятно!(
Заранее спасибо!
Старый 16.09.2009, 15:57   #2  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Такое понятие есть. Грамотно ответить на него могут Архитекторы Системы.

С Уважением,
Георгий
Старый 16.09.2009, 15:59   #3  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,765 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Грамотно ответить на него могут Архитекторы Системы
1. Не всегда
2. Если они есть, что бывает не часто
Старый 16.09.2009, 16:25   #4  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Интересно,
1. какой Архитектор скажет, что ЕГО система сконструирована НЕправильно? ;-)
2. какой Архитектор скажет, что ЧУЖАЯ система сконструирована правильно? ;-)
Старый 16.09.2009, 16:30   #5  
Lanai is offline
Lanai
Участник
 
35 / 29 (1) +++
Регистрация: 09.08.2005
Архитекторы системы - это те кто Аксапту придумывает или те грамотные люди. которые на конкретном пректе её конструируют? "Конструируют" - я имею ввиду определяют сколько должно быть аналитик например или как разбивать план счетов.

Что-то мне кажется я всё-таки не смог донести суть вопроса.(

А что по-поводу этого: имеет ли место быть такое правило и верно ли это: Если для построения отчета программистам требуется информация одновременно и по модульным проводкам и по проводкам главной книги - то это "неправильно" и свидетельствует о том что система сконструирована "неправильно" или в любом случае что-то не продумано и "не правильно" делать такие отчеты ?

И ещё тогда уж: модули - это дополнительные разрезы для главной книги? Или же они должны представлять из себя разные аналитические разрезы?

Понимаю, что может не понятно пишу, но как могу!(
Старый 16.09.2009, 16:33   #6  
Lanai is offline
Lanai
Участник
 
35 / 29 (1) +++
Регистрация: 09.08.2005
Может так: зачем таблицы для модульных проводок нужны? Для простоты реализации каких-то технических задач или они именно отражают какую-то идеологию и концепцию создания Аксапты?

Или просто для того чтобы была возможность продавать её "по-модульно"?)
Старый 16.09.2009, 16:34   #7  
AX2009
Гость
 
n/a
Пусть P(x,z) - программа P с входными аргументами x и выходными z. Пусть Q(y) - некоторое логическое условие (предикат) над переменными программы y. Язык для записи предикатов Q(y) формализовать не будем. Отметим только, что он может быть шире языка, на котором записываются условия в программах, и включать, например, кванторы. Предусловием программы P(x,z) будем называть предикат Pre(x), заданный на входах программы. Постусловием программы P(x,z) будем называть предикат Post(x,z), связывающий входы и выходы программы. Для простоты будем полагать, что программа P не изменяет своих входов x в процессе своей работы. Теперь несколько определений:

Определение 1 (частичной корректности): Программа P(x,z) корректна (частично, или условно) по отношению к предусловию Pre(x) и постусловию Post(x,z), если из истинности предиката Pre(x) следует, что для программы P(x,z), запущенной на входе x, гарантируется выполнение предиката Post(x,z) при условии завершения программы.

Условие частичной корректности записывается в виде триады Хоара, связывающей программу с ее предусловием и постусловием:

[Pre(x)]P(x,z)[Post(x,z)]
Определение 2 (полной корректности): Программа P(x,z) корректна (полностью, или тотально) по отношению к предусловию Pre(x) и постусловию Post(x,z), если из истинности предиката Pre(x) следует, что для программы P(x,z), запущенной на входе x, гарантируется ее завершение и выполнение предиката Post(x,z).

Условие полной корректности записывается в виде триады Хоара, связывающей программу с ее предусловием и постусловием:

{Pre(x)}P(x,z){Post(x,z)}
Доказательство полной корректности обычно состоит из двух независимых этапов - доказательства частичной корректности и доказательства завершаемости программы
За это сообщение автора поблагодарили: mazzy (5).
Старый 16.09.2009, 16:34   #8  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Не парьтесь.
Обычно все просто, есть задача, есть исполнитель.
Как правило исполнитель или несколько исполнителей могут спрогнозировать сколько нужно времени и к чему это приведёт(в плане производительности и всего остального).
Но не все постановщики готовы продолжать решать эту задачу за названую цену.
PS: Помню человека, который просто закормил пользователей словами низя и увы и ах. Осторожней относитесь к постулатам. И помните о цене.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему.
Старый 16.09.2009, 16:36   #9  
Alexx7 is offline
Alexx7
Сам.AX
Аватар для Alexx7
Самостоятельные клиенты AX
1C
 
305 / 28 (1) +++
Регистрация: 22.07.2009
Что то про архитектуру есть в этой ветке:
Разработка схем работы согласно логике системы
Старый 16.09.2009, 16:39   #10  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,765 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
2. какой Архитектор скажет, что ЧУЖАЯ система сконструирована правильно? ;-)
Например мы, когда делаем экспертизу. Было пару случаев, когда некоторые места системы были сделаны хорошо
Старый 16.09.2009, 16:53   #11  
ds1678 is offline
ds1678
Участник
Ex AND Project
SAP
 
84 / 50 (2) ++++
Регистрация: 12.10.2004
Адрес: SPb
Попробуйте провести декомпозицию следующего утверждения:

Система должна сделать бизнес управляемым.

Что такое "управляемый бизнес" в контексте вашего предприятия? Это точно не идентичность модульных проводок и проводок ГК. По сути вы должны проверить, на сколько предложенная модель удовлетворяет бизнес-целям и решает весь скоуп требуемых задач. Все упирается в правильную декомпозицию))
__________________
Денис Салтыков
Старый 16.09.2009, 16:59   #12  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от Vals Посмотреть сообщение
Например мы, когда делаем экспертизу. Было пару случаев, когда некоторые места системы были сделаны хорошо
Ну кто-бы сомневался, что вы всегда все хорошо делаете!
Можно еще провести экспертиху на экспертизу!
Вообще это все настолько субъективно, что даже и разговаривать не стоит! По мне, так люди, придумавшие систему классов разноски были не датчане, а голландцы, и делали они это в кофе-шопах!
За это сообщение автора поблагодарили: Wamr (-5), denny (1), Lemming (2), TasmanianDevil (2).
Старый 16.09.2009, 21:43   #13  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от AX2009 Посмотреть сообщение
{Pre(x)}P(x,z){Post(x,z)}
Доказательство полной корректности обычно состоит из двух независимых этапов - доказательства частичной корректности и доказательства завершаемости программы
И это называется Верификация.
ищите в яндексе, гугле.
http://ru.wikipedia.org/wiki/%D0%92%...86%D0%B8%D1%8F
есть и книги http://market.yandex.ru/model.xml?hi...37912531229085
__________________
полезное на axForum, github, vk, coub.
Старый 16.09.2009, 23:02   #14  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,765 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Ну кто-бы сомневался, что вы всегда все хорошо делаете!
Можно еще провести экспертиху на экспертизу!
Качество архитектурного решения можно оценивать по нескольким, достаточно формализованным критериям. Ошибки или недочёты в архитектуре чаще всего случаются и наиболее ярко видны в случае доработок системы.
Оценивая то или иное решение, можно определить несколько альтернативных путей решения поставленной задачи и сделать вывод, что автор выбрал этот путь и т.д. В этом нет ничего плохого, просто констатируется факт, что так было сделано и т.д.
Однако, очень часто, некорректные архитектурные решения и соответствующие доработки приводят к непоправимым последствиям для всей системы.
Например:
а) Выполнена доработка, которая с большой точностью повторяет стандартную функциональность.
б) Выполнена доработка, которая делает невозможным использование использование функции, части функции или целых процедур стандартной функциональности.

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

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

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

Всё, о чём я пишу взято из конкретных проектов, конкретных клиентов и решений. Прошу понять меня правильно, мы делаем очень много, чтобы поднять качественный уровень работы с ситемой. Передаём свой опыт тем, кто хочет его перенять и использовать.
Старый 17.09.2009, 11:02   #15  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от Lanai Посмотреть сообщение
Вопрос какой-то филосовский.
Скорее не философский, а политический. Можно выделить 3 основные группы заинтересованных лиц:
заказчики системы
пользователи системы
технические специалисты
Для кого-то система будет правильная, а для кого-то дурацкая. Идеал- компромисс, когда и отчеты исчерпывающие и пользоваться удобно и дорабатывать легко.
Цитата:
Сообщение от Lanai Посмотреть сообщение
Есть ли какие-либо пастулаты
Не постулаты, а критерии. Критерии правильности работы должны задаваться в начале проекта. В процессе эксплуатации критерии могут поменяться.
Цитата:
Сообщение от Lanai Посмотреть сообщение
одновременно и по модульным проводкам и по проводкам главной книги
Обычно это неправильно, но иногда это лучше, чем тащить данные из модуля в модуль. Главное ведь, чтобы данные в отчете были верны и непротиворечивы.
__________________
Isn't it nice when things just work?
Старый 18.09.2009, 14:24   #16  
BOAL is offline
BOAL
Участник
Аватар для BOAL
MCBMSS
Злыдни
1C
Лучший по профессии 2015
 
619 / 453 (17) +++++++
Регистрация: 28.04.2003
Адрес: Москва
В данном вопросе сквозит прикладной характер - успешность и неуспешность внедрения.
Формальные подходы и аудит частностей (кода, методик) - это отдельная песня, все можно и заключение получить. Но реально нужно знать одно - работает система или нет.
Если да, то ее архитектура успешна (на данный момент времени, пока не будет ясно, что масштабирование невозможно).
Если нет - то искать причины почему, составить список и устранить эти причины. Если трудоемкость и время на устранение чрезмерны (выходят за рамки проекта или суппорт запуска), то такое построение системы не удачно (или оценка проекта ошибочна в корне).

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

Решение для конкретного отчета - это уже мелочи на общем фоне - это уже не архитектура, а оптимальные алгоритмы конкретного мода.

Любой код можно сделать несколькими способами.
Он может быть краткий и красивый, но работать долго (не оптимально). Он может быть большой и запутанный, но работать жутко быстро (правильные селекты).
Чаще краткий и понятный код - оптимальный. Но не всегда.

Стандартный же функционал АХ бывает не приносит результата проекта (то есть запуска, как цели), а написанный урезанный сбоку, приносит (работает годами).
Все условно.

Заказчику без разицы (пока нет обновлений на новую версию), как внутри все сделано - работает? да! - критерий достигнут.

Это приводит нас к критериям оценки успешности проекта (часто их прописывают в регламенте опытной и промышленной эксплуатации). Если проект и система в них вошли - успех.

Если регламентов нет, критериев подавно, анализ и дизайн никто не делал, нет границ проекта и "че-то там пол-года делается", нет инструкций пользователя по всем блокам запуска, то это разводилово, поздравляю!
За это сообщение автора поблагодарили: Vals (8).
Старый 18.09.2009, 14:49   #17  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,765 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Решение для конкретного отчета - это уже мелочи на общем фоне - это уже не архитектура, а оптимальные алгоритмы конкретного мода.
Также можно добавить, что в этом случае важны правильно построенные план счетов и аналитики, если речь о финансах.
Старый 18.09.2009, 15:25   #18  
BOAL is offline
BOAL
Участник
Аватар для BOAL
MCBMSS
Злыдни
1C
Лучший по профессии 2015
 
619 / 453 (17) +++++++
Регистрация: 28.04.2003
Адрес: Москва
Да, спасибо, пока писал, мысль забылась о плане счетов.

Еще в списке к запуску - типовые проводки и статьи учета должны быть утверждены, что бы Заказчик понимал, что он получит в учете и как это потом использовать в быту.
При этом, этот список не константа (не конечный) и может изменяться самим Заказчиком без внедренца (прошел обучение по настройке сотрудник Заказчика).

В качестве одного из критериев оценки успешности используется ведение в системе замкнутого бизнес-цикла из процессов (не обязательно замкнутого именно во внедряемой Системе, может это куда-то интегрируется и там продолжает жить).

В целом же, начните с оценки проекта как такового. Построение системы - это код, настройки, правила ведения учета, документация и методология работы самого внедренца, дающая все это.

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

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Каков процент внедрений "стандартной" поставки системы Аксапта? coolibin DAX: Прочие вопросы 17 10.02.2009 12:45
Описание функциональности модуля "Аудит действий пользователей системы" D.Cheprasov DAX: Прочие вопросы 2 22.03.2004 04:32
"LIKE" и "OR" в "qbds" @x DAX: Программирование 14 20.01.2004 13:20
Введение в Аксапту Роман Кошелев DAX: Прочие вопросы 0 18.12.2001 14:00
Внедрение в группе компаний "Счастливый Кроха" Михаил Андреев DAX: Прочие вопросы 1 04.12.2001 22:42
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:11.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.