"Правильность" построения системы

[Lanai]

Добрый день!
Вопрос какой-то филосовский. Не судите строго.

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

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

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

Как-то так... Может быть не понятно!(
Заранее спасибо!

[George Nordic]

Такое понятие есть. Грамотно ответить на него могут Архитекторы Системы.

С Уважением,
Георгий

[Vals]

Цитата:

Грамотно ответить на него могут Архитекторы Системы

1. Не всегда
2. Если они есть, что бывает не часто

[egorych]

Интересно,
1. какой Архитектор скажет, что ЕГО система сконструирована НЕправильно? ;-)
2. какой Архитектор скажет, что ЧУЖАЯ система сконструирована правильно? ;-)

[Lanai]

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

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

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

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

Понимаю, что может не понятно пишу, но как могу!(

[Lanai]

Может так: зачем таблицы для модульных проводок нужны? Для простоты реализации каких-то технических задач или они именно отражают какую-то идеологию и концепцию создания Аксапты?

Или просто для того чтобы была возможность продавать её "по-модульно"?)

Пусть 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)}
Доказательство полной корректности обычно состоит из двух независимых этапов - доказательства частичной корректности и доказательства завершаемости программы

[miklenew]

Не парьтесь.
Обычно все просто, есть задача, есть исполнитель.
Как правило исполнитель или несколько исполнителей могут спрогнозировать сколько нужно времени и к чему это приведёт(в плане производительности и всего остального).
Но не все постановщики готовы продолжать решать эту задачу за названую цену.
PS: Помню человека, который просто закормил пользователей словами низя и увы и ах. Осторожней относитесь к постулатам. И помните о цене.

[Alexx7]

Что то про архитектуру есть в этой ветке:
Разработка схем работы согласно логике системы

[Vals]

Цитата:

2. какой Архитектор скажет, что ЧУЖАЯ система сконструирована правильно? ;-)

Например мы, когда делаем экспертизу. Было пару случаев, когда некоторые места системы были сделаны хорошо

[ds1678]

Попробуйте провести декомпозицию следующего утверждения:

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

Что такое "управляемый бизнес" в контексте вашего предприятия? Это точно не идентичность модульных проводок и проводок ГК. По сути вы должны проверить, на сколько предложенная модель удовлетворяет бизнес-целям и решает весь скоуп требуемых задач. Все упирается в правильную декомпозицию))

[egorych]

Цитата:

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

Например мы, когда делаем экспертизу. Было пару случаев, когда некоторые места системы были сделаны хорошо

Ну кто-бы сомневался, что вы всегда все хорошо делаете!
Можно еще провести экспертиху на экспертизу!
Вообще это все настолько субъективно, что даже и разговаривать не стоит! По мне, так люди, придумавшие систему классов разноски были не датчане, а голландцы, и делали они это в кофе-шопах!

[mazzy]

Цитата:

Сообщение от 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

[Vals]

Цитата:

Ну кто-бы сомневался, что вы всегда все хорошо делаете!
Можно еще провести экспертиху на экспертизу!

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

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

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

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

Всё, о чём я пишу взято из конкретных проектов, конкретных клиентов и решений. Прошу понять меня правильно, мы делаем очень много, чтобы поднять качественный уровень работы с ситемой. Передаём свой опыт тем, кто хочет его перенять и использовать.

[macklakov]

Цитата:

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

Вопрос какой-то филосовский.

Скорее не философский, а политический. Можно выделить 3 основные группы заинтересованных лиц:
заказчики системы
пользователи системы
технические специалисты
Для кого-то система будет правильная, а для кого-то дурацкая. Идеал- компромисс, когда и отчеты исчерпывающие и пользоваться удобно и дорабатывать легко.

Цитата:

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

Есть ли какие-либо пастулаты

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

Цитата:

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

одновременно и по модульным проводкам и по проводкам главной книги

Обычно это неправильно, но иногда это лучше, чем тащить данные из модуля в модуль. Главное ведь, чтобы данные в отчете были верны и непротиворечивы.

[BOAL]

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

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

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

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

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

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

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

Если регламентов нет, критериев подавно, анализ и дизайн никто не делал, нет границ проекта и "че-то там пол-года делается", нет инструкций пользователя по всем блокам запуска, то это разводилово, поздравляю!

[Vals]

Цитата:

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

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

[BOAL]

Да, спасибо, пока писал, мысль забылась о плане счетов.

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

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

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

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