1. Кем она разрабатывается? Неужели вы ее разрабатываете в редакторе графических схем внутри СППР? Это ведь абсолютно неудобное средство, например по сравнению с BPWin. Как вы переносите элементы с уровня на уровень?
Разрабатывается отвественными за проекты и/или тим-лидами. Правим внутри СППР. Средство для редактирования схем действительно не самое удобно, но нам для схемы самое важное — это даже не графическое представление, а связи с объектами данных, которые мы храним в соотвествующем справочнике СППР. Можно, конечно, подумать об интеграции, скажем, BPWin и СППР, чтобы схемы править с помощью графического редактора BPWin и потом каким-то образом связывать элементы схемы со справочниками СППР, но не факт что эта связка будет хорошо работать, к тому же тогда СППР перестанет быть самодостаточным продуктом. Сейчас мы рисуем схемы в СППР, СППР же делает формальные проверки этих схем (ну, например, что связи родительской схемы и дочерней не противоречивы).
Вопрос по перенос элементов с уровня на уровень не понятен. В СППР есть средства для создания дочерних схем на основе родительских — см. контекстное меню в редактора схем в СППР.
2. Вы написали, что в СППР вносятся изменения на этапе 3, при этом на этапе 5 проект может быть не готов в включению в очередной релиз. То есть изменения вносятся в какую-то ветку СППР, а затем каким то образом переносятся в основную ветку?
В СППР нет веток. Информация, отраженная там соотвествует не выпущенной версии, а разрабатываемой. Справку мы пишем в СППР уже после заливки проекта в основное хранилище, поэтому по справке не опережения выпуска, а схемы актуализируем до заливки, поэтому выпущенные схемы могут опережать выпущенный функционал.
3. Кто пишет справку, сами разработчики или отдельные технические писатели. Как синхронизирована встроенная справка и документация?
Справку пишут разработчики в СППР в рамках этапа заливки в основное хранилище, технические писатели ее проверяют в СППР (являются согласующими всех технических проектов). Заливка справки из СППР в хранилище делается централизировано в процессе сборки релиза. Документацию пишут технические писатели.
4. Как разработчики ERP смирились с тем, что запись конфигурации после небольшого изменения занимает от 40 секунд (при работе на сервере приложений) до 3 минут при файловой базе?
«Привычка свыше нам дана...» Только у нас наблюдения другие — с файловой базой, размещенной локально, конфигуратор при разработке работает быстрее, чем с клиент-серверной. А цифры примерно те же.
5. Почему в состав конфигурации входит регламентированная отчетность, которая занимает огромную часть из указанного вами объема строк кода и которая может поставляться отдельной поставкой и также отдельно обновляться?
Обновления поставляются в виде одного файла. В него входит и регл. отчетность, и, например, драйверы оборудования. Раньше все поставлялось отдельно. Это единое решение для всех конфигураций нового поколения. Так проще с организационной точки зрения, а также уменьшает количество ошибок при обновлении: ну, скажем, раньше приходилось разбираться с ошибками, что комплект отчетности подключили к версии конфигурации, которая не может с ним работать. Вообще современная тенденция — программы обновляются автоматически, ничего у пользователя не спрашивая, поэтому вообще пользователю не принципиально, какими файлами это обновление приходит. Конечно, мы понимаем, для систем уровня ERP автоматическое обновление (по крайней мере пока) скорее утопия, чем реальность. Но стремиться к этому нужно.
Так же, при изменении отчетности достаточно часто меняется не только сама отчетность, но и учетные механизмы. Например, поменяли форму журнала учета счетов фактур. Но при этом ФНС поменяла не только форму, но и иструкцию по заполнению, поэтому пришлось дописывать не только «заполнялку» регл. формы, но и учетные механизмы.
6. В СППР есть поле оценка. Кто ее выполняет и контролирует. Есть ли анализ, почему оценка была превышена, есть ли какие-то штрафы для разработчика, регулярно превышающего оценку?
Не очень понятно, о какой оценке идет речь. В СППР есть задачи, в задачах есть трудоемкость. Трудоемкость согласует рукововодитель разработки. В конце месяца делается план-фактный анализ — сколько сотрудник трудоемкости согласовал и сколько реально потратил. Информация о том, сколько реально потратил берется из ежедневных отчетов, которые мы ведем в внутренней базе «1С: Документооборот» (кстати с 1С: Документооборот интегрирована не только ERP, но и СППР — можно не выходя из СППР делать замеры фактически потраченного времени на задачу, эта информация будет хранится в 1С: Документооборот).
7. По вашей оценке, если необходимо добавить в конфигурацию в какой либо справочник новый реквизит и вывести его на форму сколько человеко-часов это потребует (хотя бы приблизительно общее количество времени на обсуждение, прототип, разработка, тестирование, справка, внесение в СППР и т.п.) "
Нет такой задачи «добавить справочник». Мы задачу формулируем так: «реализовать в программе такой-то сценарий работы». Обсуждаем мы именно эту задачу, делаем для нее прототипы. Для реализации согласованного, может потребоваться добавить справочник, и это займет сколько-то времени — но это будет просто время на разработку.
По оценке — Вы же сами понимаете, что нельзя дать оценку абстрактному «добавить справочник». Если добавить справочник «Номенклатура» со всем ее обвесом — несколько человеко-лет. Если справочник — ДрагоценныеМатериалы — часа четыре (с учетом заполнения его из макета).
Спасибо за интерес! Попробую ответить — зачем мне этот блог.
Почти всю свою программерскую жизнь я занимался написанием платформ для ERP — iScala, Epicor, потом Microsoft Dymanix (тут правда писал больше прикладной код). В самом начале 2000-х, мы с коллегами в шведской компании Scala придумали новый фреймворк/платформу ERP, основанную на метаданных и облегчающую жизнь прикладного разработчика. Чуть позже вышли ранние версии Microsoft Business Framework и наш собственный проект заморозили, считая, что Microsoft Business Framework решит все наши задачи. Но MBF так и "не взлетел", а время для реализации своего фреймворка мы упустили.
Когда я в очередной раз оказался на профессиональном распутье (поработав разработчиком, тим-лидом, директором R&D и т.д.), фирма 1С сделала мне очень интересное предложение — заняться продвижением их платформы. Про 1С я всегда был высокого мнения (т.к. были знакомые, писавшие платформу 1С), но, познакомившись поближе с нынешней платформой, я понял, что примерно вот это мы с коллегами и хотели написать лет 15 назад. Но в силу ряда причин (в том числе и отсутствия ряда экспертиз в прикладных областях) не смогли.
А в сравнении с конкурентами (которых я немало повидал, а часть из них даже написал) платформа 1С обладает огромным числом преимуществ; главные из них (на мой взгляд) — продуманная объектная модель (не нагромождение классов и таблиц, а реальные объекты из мира учетных систем с минимумом программного кода), продуманная система обновления, кросс-платформенность (в особенности наличие веб-клиента "бесплатно", без единой строчки доп. кода, и мобильный фреймворк). Понятно, что у каждой системы есть баги, недостатки. Но концепт, зерно, заложенное в основу платформы 1С — самое, на мой взгляд, правильное, по сравнению с другими продуктами, представленными на рынке.
"А мужики-то не знают!". Вот я и пытаюсь донести это до ИТ-сообщества. Парадокс ситуации в том, что чтобы понять всю прелесть платформы 1С — надо написать на C++/Java/Delphi парочку учетных систем с нуля. Понаступать на грабли, поизобретать велосипеды. А потом написать учетную систему на платформе 1С. И оценить трудозатраты.
А у нас многие разработчики 1С кроме 1С ничего не щупали. Отсюда их избалованность и пресыщенность. А ведь полезно иногда посмотреть, как выглядят проблемы пользователей/разработчиков конкурирующих систем.
Хабр же считаю самым лучшим на сегодня IT-ресурсом. Не без недостатков, конечно.
Уф, много написал, но, надеюсь, мысль — зачем мне нужен этот блог — донес.
Замечания аудитор записывает в СППР. Сюда загружается отчет о сравнении, который при загрузке парсится, по нему заполняется список измененных тех. проектом объектов. Сам отчет аудитор просматривает тоже из СППР в контексте измененных объектов. "Проглядел список измененных объектов — посмотрел что именно изменилось каждом объекте — записал замечания" — все это не выходя из СППР. Замечания регистрируются в ошибками и попадают в общий контроль сроков исправления ошибок.
Формируется отчет о сравнении ветки разработки и основного хранилища. Аудитор просматривает изменения, если нужно посмотреть более внимательно, то открывает в Конфигураторе конфигурацию ветки.
Также проверки кода делаются автоматически с помощью продукта "Автоматическая проверка конфигураций", куда в поставку заложены формальные проверки целого рядов стандартов разработки.
Непонятно разделение на "методическую проработку" и "разработку". Это неразделимые понятия при работе над таким сложным и многовариативным проектом, как "ERP". В ходе разработки ведется методическая проработка вопросов тим-лидами, ответственными за проекты, руководителем разработки. Если это необходимо, то привлекаются сторонние специалисты: проводятся консультации с представителями клиентов (логистами, фин. директорами, производственниками и т.д..), партнеров, юристами, аудиторами, специалистами по юзабилити, производительности и т.д… Это делается на протяжении всей работы над проектом: при выработке начальной концепции, при доработке концепции, при обсуждении сценариев работы пользователей, оценке интерфейсов и т.д… Будут привлекаться другие специалисты или нет, насколько будут привлекаться, на каких этапах — решается индивидуально при работе над каждым проектом.
Разработку мы ведем в хранилищах разработки, которые стоят на поддержке от основного хранилища. Это и есть наши бранчи. Создание бранчей автоматизировано и происходит с помощью СППР. При этом использует пакетный режим запуска "Конфигуратора", т.е. в принципе мы пользуемся штатными возможностями платформы. В одном бранче редко бывает необходимо нескольким разработчикам захватывать один объект.
В основном хранилище происходят заливки проектов и исправления ошибок, поэтому ситуации когда двум разработчикам нужен один объект опять-таки минимизированы, и тем более очень редко бывает, когда объект нужен надолго. В "горячую пору", когда много проектов нужно залить в основное хранилище — это после снятия моратория, связанного с выпуском версии, когда за период моратория накапливается какое-то количество проектов на заливку — мы решаем организационно, выстраивая очередь заливок. Но это не часто бывает.
С быстродействием примерно та же история — в основном хранилище разработка не ведется, поэтому фатальна скорость работы не основного хранилища, а бранчей. В бранчах же история небольшая, поэтому бранчи достаточно шустро работают.
ИМХО незаслуженно забыта отечественная разработка — мобильная платформа 1С.
Поддержка Android, iOS, Windows Phone. Краткий обзор (несколько устаревший — делался до реализации поддержки Windows).
Google Test модифицировался:
1. Из-за особенностей STL, который использует платформа
2. Для возможности тестирования dll и so компонентов из отдельного исполняемого файла — плеера тестов.
Очень интересна внутренняя база тестирования (т.н. «интеграционные» тесты на языке 1С: Предприятия)
ИМХО подобная ИБ была бы интересна многим разработчикам
Вопрос — нет ли планов вывода этой ИБ в общую доступность?
Пока не могу ничего сказать.
Тут, как у любой палки — два конца. Ценность такой ИБ для внешних разработчиков понятна.
Но, делая ИБ общедоступной, мы должны будем поддерживать стандартный цикл жизни продукта — релизы, багфиксы и т.п., т.е. расходовать на это ресурсы.
Ничего не увидел о т.н. «сценарном» тестировании, добавленном в 8.3
Статья больше про тестирование платформы. 1С: Сценарное Тестирование — продукт для тестирования прикладных решений. Понятно, что тестируя прикладные решения, мы заодно тестируем и платформу, но первичной целью продукта это все же не является.
Да, мы широко используем 1С: Сценарное Тестирование для тестов типовых конфигураций. Планируем написать об этом в одной из следующих статей.
Разрабатывается отвественными за проекты и/или тим-лидами. Правим внутри СППР. Средство для редактирования схем действительно не самое удобно, но нам для схемы самое важное — это даже не графическое представление, а связи с объектами данных, которые мы храним в соотвествующем справочнике СППР. Можно, конечно, подумать об интеграции, скажем, BPWin и СППР, чтобы схемы править с помощью графического редактора BPWin и потом каким-то образом связывать элементы схемы со справочниками СППР, но не факт что эта связка будет хорошо работать, к тому же тогда СППР перестанет быть самодостаточным продуктом. Сейчас мы рисуем схемы в СППР, СППР же делает формальные проверки этих схем (ну, например, что связи родительской схемы и дочерней не противоречивы).
Вопрос по перенос элементов с уровня на уровень не понятен. В СППР есть средства для создания дочерних схем на основе родительских — см. контекстное меню в редактора схем в СППР.
В СППР нет веток. Информация, отраженная там соотвествует не выпущенной версии, а разрабатываемой. Справку мы пишем в СППР уже после заливки проекта в основное хранилище, поэтому по справке не опережения выпуска, а схемы актуализируем до заливки, поэтому выпущенные схемы могут опережать выпущенный функционал.
Справку пишут разработчики в СППР в рамках этапа заливки в основное хранилище, технические писатели ее проверяют в СППР (являются согласующими всех технических проектов). Заливка справки из СППР в хранилище делается централизировано в процессе сборки релиза. Документацию пишут технические писатели.
«Привычка свыше нам дана...» Только у нас наблюдения другие — с файловой базой, размещенной локально, конфигуратор при разработке работает быстрее, чем с клиент-серверной. А цифры примерно те же.
Обновления поставляются в виде одного файла. В него входит и регл. отчетность, и, например, драйверы оборудования. Раньше все поставлялось отдельно. Это единое решение для всех конфигураций нового поколения. Так проще с организационной точки зрения, а также уменьшает количество ошибок при обновлении: ну, скажем, раньше приходилось разбираться с ошибками, что комплект отчетности подключили к версии конфигурации, которая не может с ним работать. Вообще современная тенденция — программы обновляются автоматически, ничего у пользователя не спрашивая, поэтому вообще пользователю не принципиально, какими файлами это обновление приходит. Конечно, мы понимаем, для систем уровня ERP автоматическое обновление (по крайней мере пока) скорее утопия, чем реальность. Но стремиться к этому нужно.
Так же, при изменении отчетности достаточно часто меняется не только сама отчетность, но и учетные механизмы. Например, поменяли форму журнала учета счетов фактур. Но при этом ФНС поменяла не только форму, но и иструкцию по заполнению, поэтому пришлось дописывать не только «заполнялку» регл. формы, но и учетные механизмы.
Не очень понятно, о какой оценке идет речь. В СППР есть задачи, в задачах есть трудоемкость. Трудоемкость согласует рукововодитель разработки. В конце месяца делается план-фактный анализ — сколько сотрудник трудоемкости согласовал и сколько реально потратил. Информация о том, сколько реально потратил берется из ежедневных отчетов, которые мы ведем в внутренней базе «1С: Документооборот» (кстати с 1С: Документооборот интегрирована не только ERP, но и СППР — можно не выходя из СППР делать замеры фактически потраченного времени на задачу, эта информация будет хранится в 1С: Документооборот).
Нет такой задачи «добавить справочник». Мы задачу формулируем так: «реализовать в программе такой-то сценарий работы». Обсуждаем мы именно эту задачу, делаем для нее прототипы. Для реализации согласованного, может потребоваться добавить справочник, и это займет сколько-то времени — но это будет просто время на разработку.
По оценке — Вы же сами понимаете, что нельзя дать оценку абстрактному «добавить справочник». Если добавить справочник «Номенклатура» со всем ее обвесом — несколько человеко-лет. Если справочник — ДрагоценныеМатериалы — часа четыре (с учетом заполнения его из макета).
Фотосессия "1С в облаках" в поддержку продукта 1cFresh.
Почти всю свою программерскую жизнь я занимался написанием платформ для ERP — iScala, Epicor, потом Microsoft Dymanix (тут правда писал больше прикладной код). В самом начале 2000-х, мы с коллегами в шведской компании Scala придумали новый фреймворк/платформу ERP, основанную на метаданных и облегчающую жизнь прикладного разработчика. Чуть позже вышли ранние версии Microsoft Business Framework и наш собственный проект заморозили, считая, что Microsoft Business Framework решит все наши задачи. Но MBF так и "не взлетел", а время для реализации своего фреймворка мы упустили.
Когда я в очередной раз оказался на профессиональном распутье (поработав разработчиком, тим-лидом, директором R&D и т.д.), фирма 1С сделала мне очень интересное предложение — заняться продвижением их платформы. Про 1С я всегда был высокого мнения (т.к. были знакомые, писавшие платформу 1С), но, познакомившись поближе с нынешней платформой, я понял, что примерно вот это мы с коллегами и хотели написать лет 15 назад. Но в силу ряда причин (в том числе и отсутствия ряда экспертиз в прикладных областях) не смогли.
А в сравнении с конкурентами (которых я немало повидал, а часть из них даже написал) платформа 1С обладает огромным числом преимуществ; главные из них (на мой взгляд) — продуманная объектная модель (не нагромождение классов и таблиц, а реальные объекты из мира учетных систем с минимумом программного кода), продуманная система обновления, кросс-платформенность (в особенности наличие веб-клиента "бесплатно", без единой строчки доп. кода, и мобильный фреймворк). Понятно, что у каждой системы есть баги, недостатки. Но концепт, зерно, заложенное в основу платформы 1С — самое, на мой взгляд, правильное, по сравнению с другими продуктами, представленными на рынке.
"А мужики-то не знают!". Вот я и пытаюсь донести это до ИТ-сообщества. Парадокс ситуации в том, что чтобы понять всю прелесть платформы 1С — надо написать на C++/Java/Delphi парочку учетных систем с нуля. Понаступать на грабли, поизобретать велосипеды. А потом написать учетную систему на платформе 1С. И оценить трудозатраты.
А у нас многие разработчики 1С кроме 1С ничего не щупали. Отсюда их избалованность и пресыщенность. А ведь полезно иногда посмотреть, как выглядят проблемы пользователей/разработчиков конкурирующих систем.
Хабр же считаю самым лучшим на сегодня IT-ресурсом. Не без недостатков, конечно.
Уф, много написал, но, надеюсь, мысль — зачем мне нужен этот блог — донес.
:)
А почему вы считаете, что это плохо?
В основном хранилище происходят заливки проектов и исправления ошибок, поэтому ситуации когда двум разработчикам нужен один объект опять-таки минимизированы, и тем более очень редко бывает, когда объект нужен надолго. В "горячую пору", когда много проектов нужно залить в основное хранилище — это после снятия моратория, связанного с выпуском версии, когда за период моратория накапливается какое-то количество проектов на заливку — мы решаем организационно, выстраивая очередь заливок. Но это не часто бывает.
С быстродействием примерно та же история — в основном хранилище разработка не ведется, поэтому фатальна скорость работы не основного хранилища, а бранчей. В бранчах же история небольшая, поэтому бранчи достаточно шустро работают.
Вы у каждого явления видите только одну сторону?
Ну и не устану повторять — ненависть лучше, чем равнодушие)
Для непубличных коммуникаций у тебя есть моя почта)
Поддержка Android, iOS, Windows Phone.
Краткий обзор (несколько устаревший — делался до реализации поддержки Windows).
Если есть заинтересованность — присылайте мне резюме на grip@1c.ru, я переправлю нашим кадровикам.
1. Из-за особенностей STL, который использует платформа
2. Для возможности тестирования dll и so компонентов из отдельного исполняемого файла — плеера тестов.
Пока не могу ничего сказать.
Тут, как у любой палки — два конца. Ценность такой ИБ для внешних разработчиков понятна.
Но, делая ИБ общедоступной, мы должны будем поддерживать стандартный цикл жизни продукта — релизы, багфиксы и т.п., т.е. расходовать на это ресурсы.
Статья больше про тестирование платформы.
1С: Сценарное Тестирование — продукт для тестирования прикладных решений. Понятно, что тестируя прикладные решения, мы заодно тестируем и платформу, но первичной целью продукта это все же не является.
Да, мы широко используем 1С: Сценарное Тестирование для тестов типовых конфигураций. Планируем написать об этом в одной из следующих статей.