iscrafm
Опыт сотен предприятий мешает сделать конкретному предприятию простейшую транзакцию, потому что она требует данных, к примеру, которых в помине нет, или не предоставляет данные, которых нет на сотнях, но есть на этом одном. И... начинаются кастомизации. Тираж превращается в "самописку", с одним отличием: ломать не строить.
Вот именно! "Ломать не строить"! И если это назвать кастомизацией, то при грамотном подходе в будущем "включить сломанное" не составит труда. Про это преимущество то и толкуется!

iscrafmчуть выше ссылку дал, показательную для этого. Ничего не разбивается (там описано сколько раз БП за год менялись, но предприятие при этом продолжало работать в "боевом режиме"). Тиражное разбилось бы быстрее, или бизнес..
Вы знаете, я все-таки решил потратить время для разбирания сего манула - интриговать Вы умеете. Скажу честно - я не увидел НИЧЕГО преимущественного перед тиражными системами.

Более того, отсутствие технической стороны вопроса не дает полной картины последствий использования и тем более оценить стоимость работ дальнейшей кастомизации. А фразы типа "ISCRA Framework, благодаря своей архитектуре, позволяла быстро адаптировать систему к любым изменениям", "Благодаря архитектуре, выбранной в качестве платформы, процесс разработки ИС сводился, по сути, к разработке ее бизнес-логики" и т.п. наводят на мысль о назначении данного конспекта в качестве рекламы и не могут использоваться в качестве показательного.

Про противоречия в сроках и архитектурных принципах, думаю, говорить уже излишне. Как и о фразах типа "в качестве СУБД может быть выбрана любая база данных" и "мощность системы наращивается путем выбора СУБД".

iscrafm
нужно было нанять архитектора. Он нужен как в разработке, так и во внедрении.
Вы знаете сколько стоит хороший архитектор, проверенный временем? )

iscrafm
А так сравниваются несравнимые вещи: в одном случае на коленках, без проработки архитектуры, разработчик спрашивает "чего нужно" у тех, кто понятия не имеет как строятся системы.. а в другом случае работает команда внедрения, которая транслирует "хотелки" в возможности готовой архитектуры. Приведите к единому знаменателю и можно будет сравнивать.
Ну почему же без проработки? Она была проработана.. на начальном этапе.
А к единому знаменателю без значительных затрат привести наколенку к тиражке НЕВОЗМОЖНО.


iscrafm
да ничего. общаемся :)
Это многообещающая позиция восприятия критики)

Infinity CreatorЭта система поставляется в виде набора описанных классов, которые привинчиваются к любой платформе в клиентской части, а монтаж БД делается на любом виде сервера с поддержкой TSQL. Без привязки к операционке или программе. Т.е. клиента на С++, а в качестве БД - оракл - да ради бога. Хотите на юниксе крутить - какие проблемы?
С тем же успехом можно рекламировать любой инструмент разработки ПО. Будь то хоть Delphi, хоть C++, хоть Java. Ограничения и безграничность думаю всем известна?

iscrafm
еще не перевелись чудаки, считающие что тиражные ERP повышают инвестиционную привлекательность
Чудаки может и не перевелись, но вот на вопросы потенциальных покупателей об ИТ-инфрастуктуре отвечать до сих пор приходится)

iscrafm
нужно было нанять архитектора. Он нужен как в разработке, так и во внедрении.

ПС
1) если бы попытались решить нанятием архитектора, стоимость владения самоделки увеличилась бы в разы.
2) при внедрении архитектор не нужен.

George Nordic
Нужен. Если речь идет о гибкой платформе, которую можно дорабатывать. И о большом проекте.


И как минимум с отсутствием аналогичных решений при кастомизации порядка выше 50%.

А в топике вроде как речь о стандартных бизнес-процессах, НЕ УРОВНЯ холдинга, включающего несколько юрлиц, при различных учетных политиках средствами одного разработчика.

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

Ок, давайте опустим разговор о сроках. Что входило в основной функционал? Интересует техническая сторона дела. Диалоговые окна (количество), отчетные формы (количество), механизмы взаимодействия окон между собой, механизмы формирования отчетов, структура базы данных (количество таблиц), бизнес-логика (количество кода, количество процедур). Какие функции у среднего звена?

Участникам.
Это только у меня пропала часть сообщений?
Были ли другие прецеденты пропадания сообщений?

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

Архитектура не интересует. И не потому, что она неинтересна, а потому что она НИ ЧЕМ не отличается от других. Свои минусы и плюсы. А вот видя "в качестве СУБД может быть выбрана любая база данных" и "мощность системы наращивается путем выбора СУБД", да еще и плюс к этому "нетиражность и малоизвестность", как технический специалист рекомендовать своему руководству такую систему я бы не стал. Даже для "малых решений".

Ну и немного своей истории.
Творчество начинал свое с разработчика - идеями и болезнями болел теми же. И так же думал - главное правильно выбрать СУБД, способ взаимодействия с ней, правильно вложить гибкость! и ПО обречено на успех!

Стороннее ПО! Фуу.. Как некрасиво! Структура не по теории! Тормознутость подсистем! Глюкавость интерфейса!

У меня же есть Delphi, SQL, книги!

Был сделан даже диск! С демкой)

Сейчас я благодарю судьбу 1) за предоставленный опыт и 2) за отсутствие ресурсов на запуск пилотного проекта.

Как оказалось, я просто не видел на тот этап всего объема предстоящих задач. А без этого адекватность рассчитываемых сил недопустима)

А видение пришло только после того, как я поработал в компании-разработчике одной из популярной российской ЕРП-системы.

И вывод один: серьезный проект не мыслим силами одного человека.

ПС: аналогия про молоток как нельзя лучше подходит для описание проблемы.

iscrafm
обзорно так:
формы ввода - 264
запросы - 122
отчеты -142
процедуры - 144
сценарии - 34

Количество человек?

iscrafm
механизмы взаимодействия окон (и других объектов) между собой - задача платформы
т.е. это уже существовало? как? если окон еще не было, как и процедур.
как можно в клиенте обратиться к другому окну/процедуре не зная его имени / id?
или же все-таки разработанные окна/процедуры регистрируются где-то в таблицах и есть требования к их структуре?
как в клиенте происходит определение, что открыть надо такое-то окно?

iscrafmСреднее звено общается с СУБД, клиент общается со средним звеном.
Я знаю для чего нужен сервер приложений. Вы мне скажите, кроме функции прослойки отвечает он еще за что-то?