BarkanСразу прошу прощения, так как об 1С практически ничего не знаю. Ж:)

Есть комплекс программ, написанных под NET 2 с базой под MS SQL, автоматизирующих учёт,
управление и планирование в заготовительном производстве машиностроительного предприятия.
В принципе ничего особенного - обычная работа с информацией, анализ с графиками и диаграммами,
отчёты и документы формируются в xls, "сложные" запросы реализованы через хранимые процедуры.

Есть коммерсанты, предлагающие для получения "продажного" продукта "переписать всё под платформу 1С".

Не совсем понятно коммерсанты предлагают создать продукт по функциональности аналогичный вашему решения для каких целей заменить вашу систему или заменить систему и еще и продавать как готовое решение?

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

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

Вообщем ценность созданной системы (не важно на чем она реализована) для продажи на сторону сомнительна.

BarkanDinamoВообщем ценность созданной системы (не важно на чем она реализована) для продажи на сторону сомнительна.

С Вами трудно не согласиться.
Я потому пока и не делаю резких телодвижений. Просто пока интересуюсь.
А коммерсанты "бьют себя пяткой в грудь" утверждая что знают куда подобный комплекс можно продать.
И мол "аналогов вообще нет".
Я их понимаю - у них интерес простой - продать и получить свой процент.
А 1С они скорее всего просто видят в качестве "паровозика".
Немного субъектива. Каждый должен заниматься своим делом в рамках своих интересов, желательно поддерживаемых компетенциями в тех или иных вопросах. Всегда, при любых условиях ищите только свой "интерес", старайтесь не принимайте на себя чужие риски и просчеты, и беритесь за работу которую сможете выполнить с большой долей вероятности. Конечно если вам очень хочется во чтобы не стало освоить 1С, то это одна стратегия, если не хотите в это влезать, а только хотите получить представление - то другая.
С учетом озвученного можно предложить такую стратегию.
Выступайте в данном проекта на ролях консультанта (эксперта) и аналитика:
- описываете сущностную модель вашей системы
- описываете функциональность вашей системы
- участвуете в формировании функциональных требований к системе (как консультант по модели работы в текущей системе)
- участвуете в тестирование функциональности системы на предмет её соответствия заявленным требованиям
- участвуете в разработке документации по продукту
- возможно участвуете в проектах внедрения этого "продукта" (опять же как консультант по заложенным в систему процессам)
Ваша зона ответственности определяется только этими задачами.
Проектирование, разработку, документирование, раскрутку, "продажи продукта" выполняет - " команда коммерсантов ".
Ваша мотивация:
- вы получаете оплату за вашу работу в проекте
- возможность поучаствовать в проекте и возможно разобраться за счет "коммерсантов" в том как устроена система 1С
- приобретаете опыт взаимодействия с разработчиками 1С (чем компетентнее будут 1С-ники тем полезнее опыт) и опыт работы в проектах в качестве консультанта и аналитика
- как вариант оговариваете условия включения вас в список авторов системы и выплаты отчислений вам процента от продаж (хотя это очень маловероятно).
Вы не несете никаких особых рисков связанных с провалом как реализации функциональности так и с ненужностью данного продукта на рынке.
Если полезете в разработку на 1С с целью создания "продукта", то вероятность получения "не оптимально спроектированного приложения" помноженная на его "сомнительную коммерческую перспективу" стремится к 0.

Gust2002The Dim!Пример ограничений языка и жестких решений пожалуйсто.
Ну если в эпоху ООП, отсутствие в языке этого самого ООП - это не ограничение, то да язык 1С - очень продвинутый.
ООП это лишь одна из технологий, причем достаточно "молодая".
ООП не является панацеей или серебряной пулей, которая "the must". Аналогично с построением деятельности основанной на бизнес-процессах, все говорят что это круто, решит все проблемы компании, рецепт преуспевания в любых условиях.
Однако компаний которые в принципе могут перейти на БП и достичь в этом направлении ощутимых результатов очень и очень немного.
Элементы ООП (с определенными ограничениями) в 1С8 заложены, и их становится все больше от версии 8.0 к 8.2. И никто не мешает использовать эти элементы при проектировании приложений.
Однако, до сих пор типовые конфигурации и большинство разработчиков используют процедурную модель.
Это я считаю связано в большей степенью с тем что над разработчиком давлеет предыдущий опыт и принципы заложенные в типовые конфигурации, а также былее высокий уровень затрат на проектирование "более ООП ориентированного" решения.
По сути такие конфигурации нужно полностью проектировать с 0 и таким решениям будет сложнее конкурировать с традиционными.
ЗАКАЗЧИК готов платить за конечный результат, за то что система выполняет решение его задач и проблем, а не за то что она разработана на основе той или иной "методологии" или технологии. Если вы предложите решение вне системы, которое будет дешевле или в рамках другой более дешевой или простой системы и будет решать проблемы Заказчика то грамотный заказчик выберет именно его.

Львиная доля успешности систем на 1С как раз в том и заключается, что не обладая значительным опытом и навыками по разработке в системе можно достаточно быстро получать конечный результат, не углубляясь в анализ процессов, выявление функциональных требований, построения концептуальной и логической модели, вопросы "физическую" реализацию и т.п (тренируясь на кошках). Безусловно платформа 1С8 требует более значительных знаний и квалификации, но пока подход остается прежним.

Для более масштабного использования подходов ООП в проектах 1С требуется:
- наличие четкой методологии проектирования и разработки решений, согласующейся с ООП
- использование этой методологии
Все это приводит к следующим, не всегда приемлемым, в рамках проектов результатам
- повышению требований к качеству документирования проекта (решения)
- увеличению объемов и сроков разработки решения за счет увеличения доли задач анализа, увеличения сложности объектной модели
- увеличению сложности анализа решения разработчиками не владеющими разработанной методикой
- повышению требований в компетенциям аналитиков и разработчиков

Вообщем, чтобы подход ООП в проектах 1С возобладал необходимы определенные усилия как со стороны профессионального сообщества (такой интерес наблюдается) так и со стороны компании 1С (а им оно надо?).
Приведу ссылку на тезисы к выпускной аттестационной работе в школе ИТ-менеджмента АНХ "Разработка методологии моделирования приложений 1С 8.2 с использованием нотаций UML".
После защиты в конце марта планирую выложить текст самой работы.

Gust2002DinamoПосле защиты в конце марта планирую выложить текст самой работы.
Интересно, но непонятно. Возьмем простой пример: документы из конфигурации "Бухгалтерия". У каждого из них есть реквизит "Организация", "Отвественный" и "Комментарий". Логично ввести сущность "ДокументБухгалтерии", где есть эти реквизиты, а остальные документы унаследовать от этой сущности. Как при этом будет выглядеть UML-диаграмма? Как по ней исполнителю реализовывать задачу?
Спасибо за вопрос, чувствуется что вы в теме
Хотел бы заметить что я не разработчик 1С8.*.
Основная цель методологии на этом этапе это "обратное проектирование" и попытка дать аналитикам не знакомым в 1С представление о том как конфигурации могут быть представлены в диаграммах.
В рамках данной работы круг задач очень ограничен, что-то будет там описано что-то нет. В перспективах будет предложены дальнейшие направления расширения методики.
Постараюсь ответить на ваш вопрос.
На уровне платформы такой возможности конечно нет, но программно просто обеспечиваете связь между документов потомком через реквизит типа ссылка на класс-родитель (можно задействовать механизм ввода на основании да тот же документ основание) и используете методы "объекта" (и как следствие класса") родителя, в том числе например алгоритмы проведения по бухгалтерским счетам. В этом случае если у вас например алгоритмы заполнения различны вы проектируете используете разные классы-родители, и соответственно разные классы потомки или например реализовав аналогичный метод в классе-потомке, который в свою очередь может частично использовать метод родителя (аналог полиморфизма).
Но как я уже говорил это достаточно серьезно усложняет как проектирование, так и дальнейшее развитие и сопровождение системы.
В 1С, в основном, используется подход процедурные когда например способы расчета значений в реквизитах табличных частей вынесены в общие модули.
При использовании фантазии можно представить модель как класс у которого нет аттрибутов, а есть только операции (методы). В принципе "ООПизация" конфигураций 1С8 как раз и может заключаться в переносе методов из модулей в специально проектируемые прикладные объекты.

Если есть интерес именно к этому вопросу предлагаю его вынести в отдельную тему чтобы не "засорять эфир".

chatmDinamo,
я еще в 2004 году пытался получить какую нибудь пользу от UML в применении к 1С . Суть заключалась в выгрузке объектов конфигурации и модулей в виде классов, с наследованием (подчиненные справочники), указанием сложных типов в реквизитах и т.д. Получилось красиво, но не пригодно в практическом применении, так как выяснилось, что методологии разработки кардинально различные.
В основном методика разрабатывалась для "обратного проектирования".
В чем я вижу необходимость рисования диаграмм по "конфигурации".
Во первых диаграммы понятна аналитикам не знакомым 1С, но знакомым с UML. Что актуально при условии когда 1С лишь одна из систем используемых в компании (у нас их например не меньше 5, все на разных технологиях и разные команды разработки ими занимаются).
Во вторых во многих средствах существует возможность разработки других диаграмм ООАП (ERD, DFD и т.д.), диаграмм требований, бизнес процессов и т.д. Описав объекты на этих диаграммах, можно на диаграммах отражающих классы конфигурации отразить взаимосвязь, что дает понимание какие понятие предметной области какими классами в разных системах представлены. В этом случае репозиторий моделей и диаграмм в комплексе может описывать все аспекты предметной области и аспекты реализации в системах. То есть чтобы понять какая функциональность есть в системе достаточно подключится к хранилищу диаграмм, а не искать в документации по разным системам где-какие функции реализованы (все прекрасно знаний по системе передаются из уст в уста, а это определенные риски). Теоретически наличие моделей снижает риски ухода команды и затраты на переход на новые системы.
В третьих ну надо же мне было какую-то тему не особо хлопотную выбрать ;).