Список форумов www.integro.ru www.integro.ru
ЦСИ ИНТЕГРО
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 

НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ
На страницу 1, 2, 3  След.
 
Начать новую тему   Ответить на тему    Список форумов www.integro.ru -> Перспективы
Предыдущая тема :: Следующая тема  
Автор Сообщение
RuslanG



Зарегистрирован: 10.07.2005
Сообщения: 171
Откуда: ИНТЕГРО

СообщениеДобавлено: Пт 06 Июн 2014 11:12    Заголовок сообщения: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ
Компанией ЦСИ «Интегро» разработана альфа-версия принципиально новой инструментальной платформы под рабочим названием «ИнСис», и мы хотели бы познакомить наших заказчиков и партнеров с некоторыми её архитектурными особенностями, которые либо уже реализованы, либо реализуются в настоящее время с переходом в рабочее использование в течение ближайших месяцев. Альфа-версия включает в себя имущественную учетную задачу в масштабе региона, создается подсистема обеспечения градостроительной деятельности, охватывающая два масштабных уровня государственного управления, а также ГИС-компонента. Разработка новой платформы позволила воспитать в нашем предприятии новое поколение разработчиков, хорошо владеющих методологическими вопросами разработки больших систем на основе каркасов приложений, шаблонов проектирования, модульного тестирования, непрерывной интеграции, а также методов DDD (Domain-driven design).
[Подробнее]

_________________
С уважением, Руслан Гадеев
Видео уроки ИнГео
Документация ИнГео
Обновления ИнГео
Интегропедия
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail Посетить сайт автора
Сергей Попов



Зарегистрирован: 05.03.2005
Сообщения: 299
Откуда: г. Тольятти - Самара - Копейск

СообщениеДобавлено: Ср 18 Июн 2014 10:57    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

Здравствуйте, Вадим Георгиевич!

Отвечаю на Ваше письмо, а более всего на ранее размещённую новость на http://integro.ru/info/doc_news_06_06_14.htm.
Перечитал, помогло, ряд банальных вопросов уже не прозвучит.
Но не подготовился, хочется не затягивать с обещанным ответом.
И так, приступаю, буду рассуждать в слух и по ходу разбираться что к чему:

1. ИнСис - это инструментальная платформа, ещё её назвали платформой интеграции. Она позволяет создавать региональные системы, автоматизирующие деятельность системы управления регионами. Чуточку сокращу повторяющиеся слова и получится: региональные автоматизированные системы управления. Звучит весомо, понятно, многообещающе.

2. В первом абзаце сказано что альфа-версия включает .... «подсистема обеспечения градостроительной деятельности, охватывающая два масштабных уровня государственного управления». Понимаю что верхний уровень для субъекта Федерации, а нижний для органов местного самоуправления. Недавно вступил в силу Федеральный закон от 27.05.2014г. №136-ФЗ, который вводит термины: городские округа с внутригородским делением и внутригородские районы. Может так случиться, что потребуется третий масштабный уровень.

3. Упомянуто вскользь «АИС ОГД муниципалитетов и региона в целом». Мне эта мысль понравилась, имею в виду «АИС ОГД региона». Надо свериться с Градостроительным кодексом, может так случиться что это там не прописано, следовательно полномочия на ведение регионом отсутствуют и заявленная задача выходит за рамки действующего законодательства. Завтра буду штудировать ГрК РФ.

4. Что конкретно будет продавать Интегро: 1) платформу ИнСис? 2) региональные автоматизированные системы управления, сделанные на базе ИнСис? Вероятно второе. Для простоты понимая проведу аналогию. Потребитель хочет яблочное пюре. Продавец может продать саженец яблони или яблоки. Второе у него вернее купят. Да и постоянно продавать яблоки выгоднее, а яблоню могут купить всего одну. Это я к тому, что продукты на базе ИнСис купить выгоднее (не в плане цены, а в плане внедрения силами опытной команды). Да и так всех потенциальных покупателей знаем на перечёт, субъектов Федерации меньше ста. Чтобы в Тольятти вкусили того пюре, надо чтобы Самарские губернаторы понимали тол в этом, чтобы прихлебатели и бюджеторастратчики посторонились, чтобы конкуренты признали что это не их хлеб, или высочайшим повелением ИнСис удостаивается звания «национальный стандарт» с автоматическим внедрением повсеместно.

5. Относительно прав доступа сказано про жёсткое определение их архитектурой административного деления. Сказано про все права сразу, т.е. и запись и про чтение. Посмотреть иногда дюже трэба, хотя бы одним глазком, понятное дело к взаимному удовольствию. Как быть? А ещё бывает что границы соседних районов друг с другом не везде стыкуются, что будет в том месте где они друг на друга накладываются? Или системы координат у них разные а не верхний уровень желательно выдать общую картину согласованных границ?

6. Очень заинтересовала та часть где говорится про ведение автоматизированных технологических процессов в рамках регламентов. Я дико извиняюсь, таки чешутся руки потрогать этот золотник.

7. ГИС-компонента является неотъемлемой частью ИнСис. Конечно ГИС будет трансформирована под те требования, которые ИнСис предъявляет всем продуктам, которые она сможет интегрировать. Сейчас ГИС «ИнГЕО» используют не только власти, но и предприятия, проектировщики, коммунальщики и геодезические конторы. ИнСис не для них, но без ИнСис они смогут пользоваться новыми версиями ИнГЕО?

А в заключении шутка. Вам решать на сколько она удалась. Меня тянет проводить аналогии, иногда это сильно помогает. Когда аналогии с природой удаются, сразу все вспоминают науку бионику, мол так и должно, стандартный подход, молодец что приметил. И так:
Начал я с того что базу данных сравнил с холодильником, а данные бывают разные как и продукты: бутылки высокие, кастрюли широкие, яйца стандартных размеров но их покупают массивами не меньше десятка. Дальше больше: пусть аналитический инструмент ИнГЕО и сторонних продуктов будут играть роль плиты - ещё один обязательный элемент современной кухни. И в результате мы сервируем стол – визуализируем в ИнГЕО и распечатываем результаты нашего труда. И так: всё необходимое на кухне есть, можно по мелочи улучшать холодильник, плиту, сервировочный стол, но из занятой ниши уже не выпрыгнуть.
А Вы решились и надеюсь у Вас получится. Вы замахнулись создавать кухни самых элитных ресторанов, где больше обслуги, выше требования, уникальные продукты, кулинары, кондитеры и шеф-повара высочайшей репутации. VIP-клиенты этих ресторанов – министры и губернаторы, а на бизнес-ленч к эти ресторации будут заскакивать мэры и главы администраций.
Ну вот, как-то так.

_________________
г. Тольятти, г. Самара, ОАО "КУЗНЕЦОВ"
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Gorbach



Зарегистрирован: 19.09.2006
Сообщения: 31
Откуда: Уфа

СообщениеДобавлено: Ср 18 Июн 2014 11:49    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

Сергей Попов писал(а):

2. В первом абзаце сказано что альфа-версия включает .... «подсистема обеспечения градостроительной деятельности, охватывающая два масштабных уровня государственного управления». Понимаю что верхний уровень для субъекта Федерации, а нижний для органов местного самоуправления. Недавно вступил в силу Федеральный закон от 27.05.2014г. №136-ФЗ, который вводит термины: городские округа с внутригородским делением и внутригородские районы. Может так случиться, что потребуется третий масштабный уровень.

3. Упомянуто вскользь «АИС ОГД муниципалитетов и региона в целом». Мне эта мысль понравилась, имею в виду «АИС ОГД региона». Надо свериться с Градостроительным кодексом, может так случиться что это там не прописано, следовательно полномочия на ведение регионом отсутствуют и заявленная задача выходит за рамки действующего законодательства. Завтра буду штудировать ГрК РФ.


Собственно, разницы нет. Пусть уровней будет сколько угодно. Все равно какие-то полномочия, а с ними и функции будут всего лишь перераспределены по уровням управления. Я как-то в статье на новостной ленте ГИС-ассоциации писал, что АИС ОГД не обязана быть с тремя уровнями (начиная с федерального), потому что в фундаменте правильной территориальной модели АИС должна лежать системная модель, которая отражает иерархию системных кластеров, а именно (снизу вверх):
- объект недвижимости (ОН);
- группа ОН (маленький имущественный комплекс);
- градостроительный квартал;
- микрорайон, городской кластер или некоторое множество кварталов (или малый населенный пункт);
- внутригородской район;
- город (большой населенный пункт);
- агломерация;
- экономический район в рамках субъекта федерации;
- субъект федерации;
- экономический район федерального уровня;
- федеральный округ (до тех пор, пока их не отменят);
- Российская Федерация.

На каждый из этих комплексов существует или может существовать своя градостроительная документация (градостроительная системная модель). В виде таких «системных сгустков» видит территорию градостроительство как дисциплина (ну, может быть, названия немного другие или я что-нибудь пропустил).
Значит все эти масштабные уровни должны быть представлены и в полноценной АИС ОГД (назовем её «ПАИСОГД»), а не АИС ОГД как она называется в нормативной базе – текущей или ближайшего будущего.
Правильно создаваемая модель предметной области на фундаментальном уровне должна отражать не текущую нормативную базу, а системную модель территории. Нормативный же взгляд – это по сути презентационный или аспектный взгляд на системную модель, ограничивающий, огрубляющий её. Или по-другому: согласие с нормативным взглядом обеспечивает декоратор системной модели. И эта нормативная модель может меняться из года в год, десятилетие или более – не важно. Главное для проектировщика системы – не ставить в основу системы изменчивый фундамент.
В том числе и поэтому я бы не стал сейчас так сильно апеллировать к градостроительному кодексу или ещё чему подобному: над системной моделью будет сделан декоратор, который будет отвечать требованиям нормативной базы, хотя внутри модели предметной области должна гнездиться и действительно гнездится куда как более богатая конструкция.

Сергей Попов писал(а):

4. Что конкретно будет продавать Интегро: 1) платформу ИнСис? 2) региональные автоматизированные системы управления, сделанные на базе ИнСис? Вероятно второе. Для простоты понимая проведу аналогию. Потребитель хочет яблочное пюре. Продавец может продать саженец яблони или яблоки. Второе у него вернее купят. Да и постоянно продавать яблоки выгоднее, а яблоню могут купить всего одну. Это я к тому, что продукты на базе ИнСис купить выгоднее (не в плане цены, а в плане внедрения силами опытной команды). Да и так всех потенциальных покупателей знаем на перечёт, субъектов Федерации меньше ста. Чтобы в Тольятти вкусили того пюре, надо чтобы Самарские губернаторы понимали тол в этом, чтобы прихлебатели и бюджеторастратчики посторонились, чтобы конкуренты признали что это не их хлеб, или высочайшим повелением ИнСис удостаивается звания «национальный стандарт» с автоматическим внедрением повсеместно.


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

Сергей Попов писал(а):

5. Относительно прав доступа сказано про жёсткое определение их архитектурой административного деления. Сказано про все права сразу, т.е. и запись и про чтение. Посмотреть иногда дюже трэба, хотя бы одним глазком, понятное дело к взаимному удовольствию. Как быть? А ещё бывает что границы соседних районов друг с другом не везде стыкуются, что будет в том месте где они друг на друга накладываются? Или системы координат у них разные а не верхний уровень желательно выдать общую картину согласованных границ?


По-моему, нет большого смысла думать о точных границах. Во всяком случае, принадлежность того или иного объекта муниципалитеты могут определить и без карты. Пространственный взгляд на территорию – это лишь один из взглядов, и на него, учитывая качество пространственных данных в Росреестре или вообще на картах, уповать не приходится. Логически отнести тот или иной объект к ведению того или иного муниципалитета можно и без карт. А когда будут точные карты, то и их можно привлекать. Поэтому, кстати, я и говорю, что ГИС-компонента – это вовсе не то для территориальных систем, что может быть единственным арбитром в сложных модельных вопросах. В идеале – да, может (когда есть точные карты), а в реальности таких точных и доступных карт не будет никогда.
Насчет прав доступа более детально расскажет Сергей Вершинин.


Сергей Попов писал(а):

6. Очень заинтересовала та часть где говорится про ведение автоматизированных технологических процессов в рамках регламентов. Я дико извиняюсь, таки чешутся руки потрогать этот золотник.


Мы ещё сами не натрогались. Smile Это будет позже. Сейчас в архитектуре есть вакантное место для техпроцессов, была разработана в прошлом году предварительная экспериментальная модель, она была попробована и… пока отложена.

Сергей Попов писал(а):

7. ГИС-компонента является неотъемлемой частью ИнСис. Конечно ГИС будет трансформирована под те требования, которые ИнСис предъявляет всем продуктам, которые она сможет интегрировать. Сейчас ГИС «ИнГЕО» используют не только власти, но и предприятия, проектировщики, коммунальщики и геодезические конторы. ИнСис не для них, но без ИнСис они смогут пользоваться новыми версиями ИнГЕО?


Мы делаем ГИС-компоненту как «отчуждаемую» от ИнСис. Точнее, при использовании ГИС-компоненты вне ИнСис, вместо последней будет стоять её сокращенный вариант, имеющий в себе только то, что используется ГИС-компонентой. Но я думаю, что, может быть, мы и не будем её вычленять как самостоятельную систему, потому что в ИнСис есть все то, что и так нужно организациям, использующим ГИС. Ведь не одну только задачу создания/редактирования/просмотра карт мы должны иметь в виду.

Сергей Попов писал(а):

А в заключении шутка. Вам решать на сколько она удалась. Меня тянет проводить аналогии, иногда это сильно помогает. Когда аналогии с природой удаются, сразу все вспоминают науку бионику, мол так и должно, стандартный подход, молодец что приметил. И так:
Начал я с того что базу данных сравнил с холодильником, а данные бывают разные как и продукты: бутылки высокие, кастрюли широкие, яйца стандартных размеров но их покупают массивами не меньше десятка. Дальше больше: пусть аналитический инструмент ИнГЕО и сторонних продуктов будут играть роль плиты - ещё один обязательный элемент современной кухни. И в результате мы сервируем стол – визуализируем в ИнГЕО и распечатываем результаты нашего труда. И так: всё необходимое на кухне есть, можно по мелочи улучшать холодильник, плиту, сервировочный стол, но из занятой ниши уже не выпрыгнуть.
А Вы решились и надеюсь у Вас получится. Вы замахнулись создавать кухни самых элитных ресторанов, где больше обслуги, выше требования, уникальные продукты, кулинары, кондитеры и шеф-повара высочайшей репутации. VIP-клиенты этих ресторанов – министры и губернаторы, а на бизнес-ленч к эти ресторации будут заскакивать мэры и главы администраций.
Ну вот, как-то так.


Мне эта аналогия понравилась, потому что она ухватывает суть системы. Если не будете возражать, то я иногда её буду применять, не всегда, правда, ссылаясь на Вас. Smile А при розливе в каком-нибудь ресторане учтем?

С уважением, Вадим
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Сергей Попов



Зарегистрирован: 05.03.2005
Сообщения: 299
Откуда: г. Тольятти - Самара - Копейск

СообщениеДобавлено: Ср 18 Июн 2014 13:09    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

Ответы меня устраивают.

Gorbach писал(а):
Мы делаем ГИС-компоненту как «отчуждаемую» от ИнСис. Точнее, при использовании ГИС-компоненты вне ИнСис, вместо последней будет стоять её сокращенный вариант, имеющий в себе только то, что используется ГИС-компонентой. Но я думаю, что, может быть, мы и не будем её вычленять как самостоятельную систему, потому что в ИнСис есть все то, что и так нужно организациям, использующим ГИС. Ведь не одну только задачу создания/редактирования/просмотра карт мы должны иметь в виду.


Это меня особенно порадовало. В последнее время в моей практике наблюдается тенденция к упадку интереса к ИнГЕО в муниципалитете (Тольятти) и устойчивый интерес у геодезических контор. Тут сильно помог модуль ОТЧЁТЫ от Самара-Информспутник.
Примерно 5 лет назад был в Уфе, видел как работают в городской архитектуре. Понравилось. Даже местами возникло ощущение работы коллектива как сплочённой команды. Всегда это заслуга конкретных людей, но не малую помощь им в этом оказывает качественный корпоративный продукт, который объединяет их усилия, облегчает их взаимодействие.
Чёрт возьми, хочется работать в такой команде.

Gorbach писал(а):
Если не будете возражать...
нет возражений.
_________________
г. Тольятти, г. Самара, ОАО "КУЗНЕЦОВ"
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Сергей Попов



Зарегистрирован: 05.03.2005
Сообщения: 299
Откуда: г. Тольятти - Самара - Копейск

СообщениеДобавлено: Ср 18 Июн 2014 15:05    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

Нельзя затягивать на долго разговор о вкусе яблока.
Собеседник может слюной подавиться или оскомину набьёт.
Минимум слов и сразу же: - "просим отведать".
А уж потом будут сравнительные анализы, обмен рецептами шарлотки и сидра, разговоры селекционеров о том, приживётся ли яблонька в наших суровых условиях, что к чему прививать, как подкармливать и чем бороться с вредителями.
Первым делом надо отведать яблоко!

Может быть сделать фиктивный (многим по душе - виртуальный) субъект Федерации и позволить попробовать себя в разных ролях. Модель субъекта породит типовой субъект и возможно наметит пути для формирования сбалансированного "идеального" субъекта.

_________________
г. Тольятти, г. Самара, ОАО "КУЗНЕЦОВ"
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
SergeyV



Зарегистрирован: 06.06.2014
Сообщения: 20
Откуда: ЦСИ "Интегро"

СообщениеДобавлено: Ср 18 Июн 2014 16:03    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

Здравствуйте, Сергей!

Попробую дополнить ответ Вадима Георгиевича некоторыми деталями.

Сергей Попов писал(а):

5. Относительно прав доступа сказано про жёсткое определение их архитектурой административного деления. Сказано про все права сразу, т.е. и запись и про чтение. Посмотреть иногда дюже трэба, хотя бы одним глазком, понятное дело к взаимному удовольствию. Как быть? А ещё бывает что границы соседних районов друг с другом не везде стыкуются, что будет в том месте где они друг на друга накладываются? Или системы координат у них разные а не верхний уровень желательно выдать общую картину согласованных границ?


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

Ресурс – это в большинстве случаев модуль базы данных, хотя здесь могут быть, например, сервисы системы или формы пользовательского интерфейса. Под модулем БД для простоты можно понимать реестр в наших старых системах.

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

На уровне реализации потенциальная доступность означает, что команды/вызовы в системе, выполняемые от имени некоторого пользователя, могут попасть в этот реестр. Если же реестр недоступен, то сама система маршрутизации команд не может направить в него команду пользователя. Еще замечу, что потенциальная доступность не соотносится с теми операциями, которые мы хотим выполнить с реестром (т.е. не задается отдельно на чтение или запись)

Определение потенциальной доступности происходит на основе того, куда в территориально-организационной иерархии привязан пользователь и ресурс (к какой организации и на какой территории). Можно провести некоторую аналогию такого разграничения с облачными системами (multi-tenant), где примерно также разграничивается доступ пользователей от разных организаций к разным данным. Только там система линейная, а в ИнСис иерархическая.

Доступность на основе роли определяется традиционным способом. В итоге пользователь может выполнить запрошенную операцию над указанным ресурсом если а) ресурс потенциально доступен б) у роли, которую имеет пользователь есть право на выполнение запрошенной операции над указанным ресурсом.

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

А что касается необходимости «иногда взглянуть одним глазком», то эту проблему можно решить тоже «традиционным» способом. Так представители одного города иногда пускают представителей другого к себе, скажем, в Главархитектуру. Так и здесь, муниципалитет может через своих администраторов временно дать доступ сотрудникам другого муниципалитета к своим данным. В этом случае посторонний сотрудник на время становится своим. Главное, что сам муниципалитет, а не какая-либо третья сторона контролирует доступ к своим данным.

Сергей Попов писал(а):

6. Очень заинтересовала та часть где говорится про ведение автоматизированных технологических процессов в рамках регламентов. Я дико извиняюсь, таки чешутся руки потрогать этот золотник.


Как сказал Вадим Георгиевич, задача пока отложена, но некоторые нюансы все-таки можно описать. Идея «встроенности» техпроцессов состоит в том, что все, с чем работают пользователи ИнСис, есть задачи. Редактирование здания – задача, поиск договоров – задача и вообще любой сценарий работы системы (use case), в рамках которого пользователь получает некоторую функциональность, есть задача. Все задачи существуют только в рамках техпроцесса. Он является контейнером задач и может определять, доступна задача в данный момент или нет. Например, логика техпроцесса может требовать, чтобы регистрация пользователем входящего обращения была выполнена до подготовки договора аренды, т.е. пока заявка не введена возможность подготовки договора закрыта.

Если нам нужно выстроить работу пользователей в рамках определенных регламентов, мы группируем задачи в техпроцессы и задаем логику «переключения задач» или так называемый маршрут. Если нет – мы просто заводим техпроцесс-контейнер, у которого отсутствует маршрут, и получаем классическую систему без техпроцесса, поскольку все задачи открыты сразу и последовательность их выполнения регулируется пользователями. У нас еще есть некоторые наработки в области техпроцессов, которые бы не имели жесткого маршрута, а развивались в соответствии с логикой жизни предметной области, но пока описать это понятным языком мы, я думаю, не готовы.

Сергей Попов писал(а):

1. ИнСис - это инструментальная платформа, ещё её назвали платформой интеграции. Она позволяет создавать региональные системы, автоматизирующие деятельность системы управления регионами. Чуточку сокращу повторяющиеся слова и получится: региональные автоматизированные системы управления. Звучит весомо, понятно, многообещающе.

Я бы здесь еще добавил, что система организации прав доступа ИнСис и тот факт, что в основе ее архитектуры лежит иерархическая территориально-административная модель, позволяет рассматривать ИнСис как:
1) платформу для построения модных нынче (и не безосновательно) SaaS-систем по управлению территориями. Скажем, некий единый региональный оператор может иметь дата-центр, где размещает ИнСис и построенную на ее базе систему управления, и подключать к такой системе муниципалитеты или регионы. Ничто не мешает ИнСис быть также и системой уровня федерального округа или РФ.

2) платформу для построения систем управления ресурсами иерархических территориально-распределенных организаций. Например, организация с развитой территориально-распределенной филиальной сетью может построить на базе ИнСис систему учета, скажем, договоров. Тогда каждый филиал сам создает договоры, контролирует оплату по ним, не имея доступа к другим филиалам, а головной офис имеет доступ ко всей информации, но не имеет права напрямую вносить в нее изменения. Кроме того, сама система головных офисов может быть многоуровневая. Например, единый головной офис находится в Москве, подчиненные ему подразделения - в округах, а подчиненные им филиалы – в конкретных городах.


Надеюсь, что мне удалось внести дополнительную ясность. Если нет, буду рад ответить на дополнительные вопросы.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Сергей Попов



Зарегистрирован: 05.03.2005
Сообщения: 299
Откуда: г. Тольятти - Самара - Копейск

СообщениеДобавлено: Ср 18 Июн 2014 17:14    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

SergeyV писал(а):
Надеюсь, что мне удалось внести дополнительную ясность
Да, благодарю!
_________________
г. Тольятти, г. Самара, ОАО "КУЗНЕЦОВ"
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Сергей Попов



Зарегистрирован: 05.03.2005
Сообщения: 299
Откуда: г. Тольятти - Самара - Копейск

СообщениеДобавлено: Чт 19 Июн 2014 07:50    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

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

Допустим такую ситуацию:
Подразделения на местах (подразделение) ведут договора с поставщиками.
Если есть нарекания на работу поставщика (сроки, качество) то всю претензионную работу с данным поставщиком по конкретному контракту ведёт головной офис (офис). Инициаторами выступают подразделения. Офис получает всю необходимую информацию из подразделения, пополняет и ведёт свой ресурс «претензии», который интересен всем подразделениям в урезанном виде: подтверждение получение офисом претензии, общая информация о текущей стадии претензии, «чёрный» и «серый» списки контрагентов. Т.е. взаимный информационный обмен, при котором офис видит всю информацию подразделений, а подразделения только некоторую информацию офиса.
Надеюсь такая ситуация может иметь место в ИнСис.
Справочник поставщиков: структура данного справочника у всех одинакова, но кто его ведёт: каждое подразделение, офис?

Ещё один пример:
Архитектура ведёт адресный реестр (справочник) и адресный план (связь значений справочника с территориально расположенными объектами).
Считаем что это серьёзная основа для многих отраслевых реестров, которые используют адреса.
Если производится снос здания, я так понимаю что его адрес нельзя изымать из реестра, так как начнутся ссылочные коллизии. Присваивать высвободившийся адрес другому объекту тоже чревато.

Архитектура начинает собирать исходные данные для очередного Генплана. Она хочет видеть из отраслевых ресурсов агрегирующую информацию с привязкой к конкретным зданиям (адресам). Между архитектурой и отраслевыми предприятиями нет иерархии, формирование агрегирующей информации нет необходимости делать постоянно, достаточно сделать снимок на конкретную дату.

Ещё возможен вариант информационного взаимодействия предприятий коммунальной (любой другой) сферы на основе взаимозачётов. Оценили стоимость одного пакета информации, оформили друг другу кредит на первоначальную порцию пакетов и начинают считать каждый месяц: кто сколько информации запросил. Электросеть получила от Водоканала 500 и предоставила 200 пакетов. В конце месяца должна заплатить за 300 пакетов.
В принципе такое может быть реализовано?

_________________
г. Тольятти, г. Самара, ОАО "КУЗНЕЦОВ"
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
SergeyV



Зарегистрирован: 06.06.2014
Сообщения: 20
Откуда: ЦСИ "Интегро"

СообщениеДобавлено: Чт 19 Июн 2014 16:17    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

Сергей, здравствуйте!
К сожалению, немного не достает времени на полный ответ, поэтому отвечу пока на часть, а остальное напишу чуть позже.
Сергей Попов писал(а):

Подразделения на местах (подразделение) ведут договора с поставщиками.
Если есть нарекания на работу поставщика (сроки, качество) то всю претензионную работу с данным поставщиком по конкретному контракту ведёт головной офис (офис). Инициаторами выступают подразделения. Офис получает всю необходимую информацию из подразделения, пополняет и ведёт свой ресурс «претензии», который интересен всем подразделениям в урезанном виде: подтверждение получение офисом претензии, общая информация о текущей стадии претензии, «чёрный» и «серый» списки контрагентов. Т.е. взаимный информационный обмен, при котором офис видит всю информацию подразделений, а подразделения только некоторую информацию офиса.
Надеюсь такая ситуация может иметь место в ИнСис.


Да, такая ситуация может иметь место в ИнСис. Один из вариантов реализации такой. Вводим следующие реестры.
    Реестр договоров – ведется подразделениями, каждое из них видит только свои договоры. С уровня офиса виден сводный реестр договоров, и виден он на чтение.
    Реестр запросов на претензии – ведется подразделениями, разные подразделения видят только свои запросы, их стадии и т.п.
    Реестр претензий – ведется офисом, но виден и в подразделениях. Причем, потенциально виден. На деле, отдельных средств на просмотр именно этого реестра у подразделений нет. Они смотрят на него через «призму» запросов на претензии. Это позволяет сделать так, что подразделения видят только свои претензии.

Процесс работы выглядит так. Подразделение регистрирует запрос на претензию. Офис видит запрос и создает собственно претензию, привязанную к запросу. С момента привязки подразделение видит, что запрос получен и по нему создана претензия. Также по ходу работы офиса с претензией подразделение видит изменение его статуса.

Сергей Попов писал(а):

Справочник поставщиков: структура данного справочника у всех одинакова, но кто его ведёт: каждое подразделение, офис?

Тут, как мне кажется, несколько вариантов. Первый – реестр общий и его ведут все, но тогда все друг другу будут мешать, изменяя чужие данные. Второй – реестр единый, но за внесение в него данных отвечает офис, что будет неудобно. Третий – каждый ведет свой реестр с единой структурой, но тогда будут дублировать данные. Четвертый – каждый ведет свою часть реестра, но видит сводный реестр. Так данные тоже могут быть сдублированы, но вероятность ниже, поскольку можно посмотреть, не ввел ли уже кто-то нужного поставщика. Если нет – добавить своего и уже он будет доступен всем остальным. Но тогда при необходимость скорректировать данные нужно обращаться в подразделение-автор или заводить копию. Все варианты с недостатками, но все их можно сделать в ИнСис.

Что касается «черных» и «серых» списков контрагентов, то их я бы сделал реестром на уровне офиса, который просто доступен на чтение всем подразделениям. Естественно, что его данные пользователи видят через призму реестра поставщиков, о котором сказано выше (если здесь контрагенты = поставщики, в противном случае нужны еще требования). Т.е. мы здесь выносим информацию о статусе поставщика в смежный реестр и настраиваем его доступность отдельно. В данном случае делаем доступ на изменение только со стороны офиса.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
SergeyV



Зарегистрирован: 06.06.2014
Сообщения: 20
Откуда: ЦСИ "Интегро"

СообщениеДобавлено: Чт 19 Июн 2014 18:39    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

Продолжаю ответ.

Сергей Попов писал(а):

Ещё один пример:
Архитектура ведёт адресный реестр (справочник) и адресный план (связь значений справочника с территориально расположенными объектами).
Считаем что это серьёзная основа для многих отраслевых реестров, которые используют адреса.
Если производится снос здания, я так понимаю что его адрес нельзя изымать из реестра, так как начнутся ссылочные коллизии. Присваивать высвободившийся адрес другому объекту тоже чревато.

Архитектура начинает собирать исходные данные для очередного Генплана. Она хочет видеть из отраслевых ресурсов агрегирующую информацию с привязкой к конкретным зданиям (адресам). Между архитектурой и отраслевыми предприятиями нет иерархии, формирование агрегирующей информации нет необходимости делать постоянно, достаточно сделать снимок на конкретную дату.

Я немного не понял, в чем конкретно здесь вопрос, поэтому попробую предположить и дать ответ, исходя из этого. Вообще говоря, и архитектура, и отраслевые предприятия все же являются подузлами единой иерархии. Если последние – это предприятия муниципального уровня (например, городской Водоканал), то они входят в иерархию муниципалитета. Если предприятие имеет статус регионального (ну, к примеру, региональное отделения Газпрома), то оно будет в региональной иерархии, в которой архитектура тоже есть (правда не одна, а в каждом муниципалитете).

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

Ещё возможен вариант информационного взаимодействия предприятий коммунальной (любой другой) сферы на основе взаимозачётов. Оценили стоимость одного пакета информации, оформили друг другу кредит на первоначальную порцию пакетов и начинают считать каждый месяц: кто сколько информации запросил. Электросеть получила от Водоканала 500 и предоставила 200 пакетов. В конце месяца должна заплатить за 300 пакетов.
В принципе такое может быть реализовано?

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



Зарегистрирован: 05.03.2005
Сообщения: 299
Откуда: г. Тольятти - Самара - Копейск

СообщениеДобавлено: Пт 20 Июн 2014 14:57    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

Добрый день!
Так как ИнСис это не конечный продукт, то предлагаю делить и явно подразумевать когда речь идёт об ядре ИнСис и оболочке вокруг ядра, в которую входят программы, модули, комплексы в том числе и сторонних разработчиков.
В ядре реализуются минимум основополагающего кода и закладываются некоторые ограничения, которые действуют на всё что будет входить в оболочку. Оболочку воспринимаем как потенциальную возможность и как уже реализованные блоки.
Ядро строится на выбранных принципах, один из которых - иерархическая система.
По сути, я согласен с озвученными принципами и вроде как при ближайшем рассмотрении, пояснении, выясняется что и ограничений нет.
Можно сделать всё на что хватит фантазии.

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

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

Вопрос: ДОЛЖНОСТи-РОЛи-ЧЕЛОВЕК.
Конкретный человек занимает конкретную должность, которой соответствует роль. Допустим временно (отпуск или болезнь) на этого сотрудника возлагают обязанности ещё одной должности (возможно в другом подразделении: начальник управления может исполнять обязанности руководителя департамента в состав которого он входит) с другой ролью.
Как это будет выглядеть в ИнСис? Придётся сотруднику входить в систему под разными логинами чтобы объяснить системе о том в качестве кого он в данный момент работает, или уже в системе он сможет оперативно поменять свою роль из списка доступных ролей?
Интересно фиксировать информацию о периодах закрепления ролей за каждым человеком.

_________________
г. Тольятти, г. Самара, ОАО "КУЗНЕЦОВ"
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
SergeyV



Зарегистрирован: 06.06.2014
Сообщения: 20
Откуда: ЦСИ "Интегро"

СообщениеДобавлено: Пт 20 Июн 2014 22:52    Заголовок сообщения: Re: НОВАЯ ПЛАТФОРМА РАЗРАБОТКИ РЕГИОНАЛЬНЫХ СИСТЕМ Ответить с цитатой

Сергей Попов писал(а):

Так как ИнСис это не конечный продукт, то предлагаю делить и явно подразумевать когда речь идёт об ядре ИнСис и оболочке вокруг ядра, в которую входят программы, модули, комплексы в том числе и сторонних разработчиков.
В ядре реализуются минимум основополагающего кода и закладываются некоторые ограничения, которые действуют на всё что будет входить в оболочку. Оболочку воспринимаем как потенциальную возможность и как уже реализованные блоки.
Ядро строится на выбранных принципах, один из которых - иерархическая система.

Ещё один аспект обсуждения: где провести грань между ядром и оболочкой.


Это довольно сложный вопрос, где ядро, а где оболочка. Допустим, ядро-это механизм описания реестров, их хранения и представления. Плюс, все ресурсы системы встроены в некоторую абстрактную иерархию. Вроде бы, это и есть ядро. Наполняй его конкретными реестрами, представляй их пользователю и получишь оболочку. Так было, например, с ИнМетой (за исключением иерархий, правда). С другой стороны, почему бы не добавить прямо к ядру ФИАС€ Все объекты учета в разных предметных областях так или иначе связаны с адресами. В итоге мы получим ядро, только немного более специализированное. Теперь мы, к примеру, добавляем в систему административное и кадастровое деление, сужая тем самым область возможных применений сферой управления территориями РФ. Но ведь это тоже ядро, только еще более специализированное и предназначенное для определенного класса систем.
Получается, что можно выделить ядра нескольких уровней. И над каждым из них может строится оболочка. Если она достаточно общая, то и она тоже даст ядро следующего уровня и т.д.

Сергей Попов писал(а):

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


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

Предложенный вариант мне тоже нравится, и с точки зрения реализации мне он кажется очень близким к упомянутому четвертому. А именно: часть реестра, которую ведет офис – глобальная, части, которые ведут подразделения – локальные и временные. Я только позволю себе немного упростить. Допустим, что когда подразделение создает в своей части объект, оно не пересылает в офис, а просто офис контролирует сводный реестр на предмет появления в нем локальных записей подразделений и по мере их появления переносит их в глобальный. При этом никакого «переключения» данных на новое значение не происходит, просто объект мигрирует из одной части реестра в другую, сохраняя свой идентификатор. Ну либо же, если в локальных частях появились дубликаты, то происходит их слияние с переустановкой ссылок на единое значение.

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

Сергей Попов писал(а):

Вопрос: ДОЛЖНОСТи-РОЛи-ЧЕЛОВЕК.
Конкретный человек занимает конкретную должность, которой соответствует роль. Допустим временно (отпуск или болезнь) на этого сотрудника возлагают обязанности ещё одной должности (возможно в другом подразделении: начальник управления может исполнять обязанности руководителя департамента в состав которого он входит) с другой ролью.
Как это будет выглядеть в ИнСис? Придётся сотруднику входить в систему под разными логинами чтобы объяснить системе о том в качестве кого он в данный момент работает, или уже в системе он сможет оперативно поменять свою роль из списка доступных ролей?
Интересно фиксировать информацию о периодах закрепления ролей за каждым человеком.


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

Насчет фиксации закрепления ролей – хорошая мысль, спасибо! Внес ее в список предложений.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
nawakster



Зарегистрирован: 17.06.2008
Сообщения: 59

СообщениеДобавлено: Сб 28 Июн 2014 03:07    Заголовок сообщения: Ответить с цитатой

В теории все красиво интересно, всякие архитектурные решения и т.д.

Пожелания, на основе опыта самостоятельного внедрения Мониторинга.
1.Документация. То что, прилагалось к Инмете - это ад. Последняя версия инметы 2012г, документации 2009. Даже не знаю, можно ли это назвать документацией вообще - так внутренний рабочий документ. Хорошо Власов немного помогал. Об учебнике по Инмете (gis.su - любезно поделились) я случайно узнал через год внедрения, да и тот не дописан.

2.Тесная связь с Ингео, чтобы поменьше писать кода для сохранения данных из реестра в Ингео.

3. Всякие сервисные операции. О существовании утилиты удаления дубликатов в реестрах я узнал через 2 года. Это должно делаться легко и просто в администрировании системы.

Если отмотать время назад, не в жизнь бы не связался с Мониторингом. По сути от всей системы нужны были только реестры. Почему? - потому, что это никому не нужно. Используется только в пределах комитета. Документооборот ведется в лотусе, и тех процессы там.
Поэтому было проще взять XAF от DevExpress. И не особо мучаясь реализовать все это там.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
SergeyV



Зарегистрирован: 06.06.2014
Сообщения: 20
Откуда: ЦСИ "Интегро"

СообщениеДобавлено: Сб 28 Июн 2014 18:58    Заголовок сообщения: Ответить с цитатой

Здравствуйте!

nawakster писал(а):
1.Документация. То что, прилагалось к Инмете - это ад. Последняя версия инметы 2012г, документации 2009. Даже не знаю, можно ли это назвать документацией вообще - так внутренний рабочий документ. Хорошо Власов немного помогал. Об учебнике по Инмете (gis.su - любезно поделились) я случайно узнал через год внедрения, да и тот не дописан.

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

ГИС-компонента является частью ИнСис, т.е. нет двух систем – есть одна. И если в ней создан объект, то он просто может иметь пространственные параметры, а может их не иметь (раньше это бы означало, что в ИнМете объект есть, а в ИнГео – нет). Семантика тоже хранится в одном месте, поэтому вопрос ее переноса между системами появляться не должен.
nawakster писал(а):
3. Всякие сервисные операции. О существовании утилиты удаления дубликатов в реестрах я узнал через 2 года. Это должно делаться легко и просто в администрировании системы.

В ИнСис будет единая расширяемая среда администрирования системы, в которую будут включаться все сервисные утилиты (за исключением тех, которые будут в силу каких-нибудь причин плохо вписываться в эту среду). Кстати говоря, надеюсь, что наши партнеры тоже примут участие в написании к ней плагинов.
nawakster писал(а):
По сути от всей системы нужны были только реестры. Почему? - потому, что это никому не нужно. Используется только в пределах комитета. Документооборот ведется в лотусе, и тех процессы там.
Поэтому было проще взять XAF от DevExpress. И не особо мучаясь реализовать все это там.

Собственно говоря, реестры и выходные документы – это и есть Мониторинг. В отличие, кстати, от XAF, которая – просто Framework, на базе которого нужно было бы все эти реестры еще и создать.
nawakster писал(а):
Если отмотать время назад, не в жизнь бы не связался с Мониторингом.

Очень жаль, что работа с нашими системами оставила у Вас такое неприятное впечатление. Мы постараемся, чтобы с ИнСис все было наоборот Very Happy В связи с этим было бы интересно узнать, есть ли еще что-то, что Вы хотели бы видеть в новой системе?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Сергей Попов



Зарегистрирован: 05.03.2005
Сообщения: 299
Откуда: г. Тольятти - Самара - Копейск

СообщениеДобавлено: Сб 28 Июн 2014 20:41    Заголовок сообщения: Ответить с цитатой

SergeyV писал(а):
... есть ли еще что-то, что Вы хотели бы видеть в новой системе?
Да! Как вы смотрите на реализацию третьей координаты? И ЭТА КООРДИНАТА НЕ Z! Это время!!!
Пример:
По началу мы думали что Правила землепользования и застройки - это статичный документ. Ошибались все до одного. Когда стали вноситься изменения в ПЗЗ, до нас дошло, что надо выделить ДЕЙСТВУЮЩУЮ редакцию (с даты опубликования) и все предыдущие редакции (интервал их действия). Выбираем нужную дату и вуалая: видим то, что действовало именно в тот момент.

А Генеральный план? Тут сразу несколько чертежей: фактическое положение дел на момент разработки ГП, варианты развития города с разложением на этапы. Переход от этапа к этапу не происходит везде и сразу по приказу. Надо утвердить проект планировки чтобы иметь возможность в конкретном месте двигаться дальше: вносить изменения в ПЗЗ.

Другой пример: город развивается, строятся и сносятся здания, прокладываются дороги, выгорают тысячи гектаров леса. Хочется выбрав масштаб скорости изменения времени увидеть этот процесс как в мультипликационном фильме.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
nawakster



Зарегистрирован: 17.06.2008
Сообщения: 59

СообщениеДобавлено: Пн 30 Июн 2014 01:23    Заголовок сообщения: Ответить с цитатой

Пожелания. мм..
1. Документацию - обещаете.
2. Тесную связь с Ингео - обещаете.
3. Удобное администрирование - обещаете.
4. Удобную среду разработки - С инмета я познал все прелести разработки в блокноте. . На диски(комитет 2 раза мониторинг покупал и содержание дисков отличалось значительно), забыли положить почему-то xmlbuilder. Каша из XML, VBScript, html и SQL без автокомплита и отладки - редкостный мазохизм. Через годик, когда я увидел xmlbuilder - он меня тоже не особо обрадывал. В блокноте мне уже было проще и быстрее.
Если верить статье, то в Инсис я бы познал все прелести разработки - VS, C#, ORM, Linq. Как это выглядит непонятно, но удобство разработки обещаете. Хотелось бы еще реализацию подхода "Model First". Как во всех продвинутых ORM.
5. Интерфейс. У Инметы он практически не настраивается. Я не про отображение данных, а про элементы. Вот например, поле ассоциации - поиск осуществляется с первого введенного символа, из-за этого постоянно подвешивается база. Чего проще, сделать поиск после трех введенных символов, но мне никак.
В Инсис - обещаете ExtJs. Это интересно. Вопрос, конечно, в скорости.

А про неприятное впечатление о системах. К Ингео у меня вообще никаких претензий, я абсолютно всем доволен. У меня за 7 лет работы ни одной нерешаемой проблемы не возникло. А с Инметой-Мониторингом не повезло. Наверное, я слишком много ожидал. Продукт сырой и явно не рассчитан на самостоятельное внедрение.

Почему я XAF упомянул. У меня на данный момент стоит вопрос, что делать дальше с Мониторингом. Документации не было, нет и не будет. 2 года никаких обновлений. Поддержкой я тоже не особо доволен - у вас даже на форуме половину вопросов без ответов.
Пользователям вот, например, нужен быстрый вывод реестров, с удобным поиском и фильтрацией, экспортом в excel. В Инмете - стандартный вывод ужасный. Экспорт в excel - не для среднего пользователя. Конечно, есть HTTP протокол, который коряво описан в документации. Но к чему мне опять этот геморрой. Проще напрямую данные из базы получить. Если завтра уволюсь всю эту кухню поддерживать будет некому.
Почему выбрал XAF - скорость разработки, интеграция в VS, ORM c "Model First", C#, шикарная документация. XAF - одновременно web и winforms приложение. Я завернул winforms приложение в dll и подключил, как COM модуль к Ингео.

А Инсис, думаю, через пару лет допилите до релиза. Но я тогда уже уволюсь, скорей всего)
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
SergeyV



Зарегистрирован: 06.06.2014
Сообщения: 20
Откуда: ЦСИ "Интегро"

СообщениеДобавлено: Пн 30 Июн 2014 12:47    Заголовок сообщения: Ответить с цитатой

Сергей Попов писал(а):
Как вы смотрите на реализацию третьей координаты? И ЭТА КООРДИНАТА НЕ Z! Это время!!!

Ах, время… Очень желаемая (даже необходимая) вещь, но очень непростая. Скажу так, мы не видим ИнСис без историзма. Он обсуждается, но каким он будет и насколько скоро, пока сказать сложно.

На данный момент мы технически можем сделать следующее. Если с каким-либо объектом предметной области происходит изменение (меняются поля, структура и т.п.), его предыдущая версия становится неактивной, а интервал ее времени жизни закрывается датой внесения изменений, после чего активной становится новая версия объекта. Соответственно, репозиторий объектов мог бы иметь методы для запроса объектов с учетом времени: можно получить версию объекта, которая была активна на указанный момент времени. Но это – историзм системный. Если взять Ваш пример с мультфильмом про развитие города, то мы увидим не развитие самого города, а развитие его описания в системе, т.е. кто и когда вводил в систему данные. То же и с ПЗЗ. Например 1.01.2001 мы внесли в систему ограничение на этажность домов в определенной зоне не более 4-х, но оказалось, что это просто опечатка, и максимальная этажность – 9. Мы эту ошибку обнаружили 12.03.2001 и исправили. Теперь если мы запросили ограничение для зоны на 1.02.2001, мы получим 4 этажа, а на 1.04.2001 – 9 этажей. Хотя правильно было бы в обоих случаях иметь 9.

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



Зарегистрирован: 19.09.2006
Сообщения: 31
Откуда: Уфа

СообщениеДобавлено: Пн 30 Июн 2014 14:13    Заголовок сообщения: Ответить с цитатой

nawakster писал(а):
Пожелания. мм..
1. Документацию - обещаете.
2. Тесную связь с Ингео - обещаете.
3. Удобное администрирование - обещаете.
4. Удобную среду разработки - С инмета я познал все прелести разработки в блокноте. . На диски(комитет 2 раза мониторинг покупал и содержание дисков отличалось значительно), забыли положить почему-то xmlbuilder. Каша из XML, VBScript, html и SQL без автокомплита и отладки - редкостный мазохизм. Через годик, когда я увидел xmlbuilder - он меня тоже не особо обрадывал. В блокноте мне уже было проще и быстрее.
5. Интерфейс. У Инметы он практически не настраивается. Я не про отображение данных, а про элементы. Вот например, поле ассоциации - поиск осуществляется с первого введенного символа, из-за этого постоянно подвешивается база. Чего проще, сделать поиск после трех введенных символов, но мне никак.

А про неприятное впечатление о системах. К Ингео у меня вообще никаких претензий, я абсолютно всем доволен. У меня за 7 лет работы ни одной нерешаемой проблемы не возникло. А с Инметой-Мониторингом не повезло. Наверное, я слишком много ожидал. Продукт сырой и явно не рассчитан на самостоятельное внедрение.

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

Пользователям вот, например, нужен быстрый вывод реестров, с удобным поиском и фильтрацией, экспортом в excel. В Инмете - стандартный вывод ужасный. Экспорт в excel - не для среднего пользователя. Конечно, есть HTTP протокол, который коряво описан в документации. Но к чему мне опять этот геморрой. Проще напрямую данные из базы получить. Если завтра уволюсь всю эту кухню поддерживать будет некому.
А Инсис, думаю, через пару лет допилите до релиза. Но я тогда уже уволюсь, скорей всего)


Здравствуйте, nawakster!

Да, мы в курсе недостатков некоторых наших продуктов и даже много более, чем Вы написали. Smile И должен сказать, что новая платформа потому и начала делаться руками молодежи, что она не обременена старыми догмами сильно повзрослевших некоторых наших разработчиков. К сожалению, такая стадия всегда случается в долгоживущих компаниях и требует смены поколений лидеров, потому что некоторые старые кадры, порой, сильно против той идеи, что надо постоянно развивать себя. Поэтому пишете Вы правильно, и мы эти недостатки уже много лет видим и ими недовольны. Но как всегда некоторым людям надо пройти через личную драму, чтобы понять, что старые заслуги не снижают требования к лидерам постоянного и даже опережающего обновления своих взглядов причем с учетом других мнений, а не только своего. Или уйти.
Теперь у нас есть свой богатый опыт жития в технологическом разрыве, что я считаю самым полезным для компании. Все будет нормально с новой платформой. И она будет развиваться совсем иначе, чем старая, потому что делают её много людей, более чувствительных к новому и более учитывающих мнения товарищей. И эта новая группа будет все время принудительно обновляться и/или расширяться, чтобы не было застоя в головах. Smile

Насчет второго, - а именно того, что в организациях кто-то из программистов надеется, что он один вытянет некий инструмент в деле решения предметных задач. Увы все мы здесь понимаем, что в госструктурах надеяться, будто она сама с помощью одного-двух своих программистов сделает что-то эпохальное, легко развивающееся - это иллюзия. Использование любой платформой (вот Вы говорите про XAF) в такой организации всё равно обречена на провал, потому что какой бы ни был в ней крутой программист, он проработает недолго и уйдет на другие хлеба (я знаю только одного зубра - Олега Буракова, который един во всех лицах и надежен для организации). И поэтому все равно придется постоянно обращаться за тонкостями внедрения в разработчикам. Организация так или иначе попадет в зависимость от своего разработчика, причем куда как более тяжелую, чем от внешней компании, которая просто умеет "мучиться" со своей платформой, какой бы неудобной для развитого программиста она ни была и имеет не одного человека, умеющего это. Если платформа простая (хоть и не без недостатков), но она позволяет решать задачи без привлечения очень и очень квалифицированных программистов, то это тоже - плюс. Такие люди в подавляющем своем большинстве достаточно капризны и опираться на них госструктурам трудно, потому что свободы у руководства в деле повышения заинтересованности таких кадров минимальны. И Вы правильно опасаетесь: "Если завтра уволюсь всю эту кухню поддерживать будет некому". Сильным программистам уволиться и найти себе более доходную и интересную работу в крупном городе очень легко.
Поэтому надо работать с нами, а не мучиться самому. У нас есть инструменты, облегчающие жизнь разработчика. Но нам трудно обучить всему этому внешних программистов. Т.е. работать с нами заказчику будет надежнее. Просто руководство некоторых заказчиков думает, что его один-два программиста решат все задачи, и их использовать будет дешевле. Да, некоторое время будет дешевле, а в конечном счете много дороже и опаснее, потому что в наработанном таким программистом коде после его ухода уже и мы не разберемся. Так что свой программист в организации заказчика - это игла потолще будет, чем наша.
Ну, а с критикой я полностью согласен и во многом узнаю свои слова и других наших разработчиков нескольких лет давности. Smile Но я бы добавил ещё несколько штучек и по-фундаментальнее. Однако же, не буду по понятным причинам. Smile Мы сейчас развиваемся, в т.ч. и в области ИнМеты. Так что, спасибо за разборку.

С уважением, Горбачев
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Gorbach



Зарегистрирован: 19.09.2006
Сообщения: 31
Откуда: Уфа

СообщениеДобавлено: Пн 30 Июн 2014 14:24    Заголовок сообщения: Ответить с цитатой

Кстати, хочу заметить рефреном с первым сообщением...

nawakster писал(а):

Почему выбрал XAF - скорость разработки, интеграция в VS, ORM c "Model First", C#, шикарная документация. XAF - одновременно web и winforms приложение. Я завернул winforms приложение в dll и подключил, как COM модуль к Ингео.

А Инсис, думаю, через пару лет допилите до релиза. Но я тогда уже уволюсь, скорей всего)


Могу смело поспорить, что пришедший Вам на смену программист не осилит XAF вместе с Вашими наработками. Smile Так что XAF абсолютно не спасет Вашу нынешнюю организацию, а как раз наоборот. Если только то, что Вы наработаете, не слишком мало, конечно. И чем больше Вы наработаете, тем трагедия для организации будет бОльшая, - вплоть до полного отказа от наработанного и опускание до полного нулевого уровня информатизации. Sad
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
nawakster



Зарегистрирован: 17.06.2008
Сообщения: 59

СообщениеДобавлено: Пн 30 Июн 2014 16:14    Заголовок сообщения: Ответить с цитатой

Gorbach
А я с Вам согласен на 100%.
Переписать код с нуля - это самое ужасное, что можно придумать. Когда возникают такие мысли обычно перечитываю Спольски http://habrahabr.ru/post/219651/

Выше написал, почему мысли меня не покидали. Но главные 3 причины:
1. Отсутствие документации и поддержки.
2. Отсутствие апдейтов уже больше, чем 2 года. Да и до этого, апдейты были чисто косметические. Никаких новых фич.
Я написал пару раз об этом в том году и в этом на суппорт, Власову и вот на форуме http://www.integro.ru/forum/viewtopic.php?t=1386. Ни ответа, ни привета.
Зато в прайсе появилась строчка Лицензия на систему продаётся при условии, что заказчик планирует в дальнейшем внедрение этой системы силами нашей компании или авторизованных партнёров.))
Я думал вы совсем забили на продукт.
3. У меня первые пару месяцев был шок от Мониторинга. После Ингео я такой подставы не ожидал)) Даже вменямой инструкции по установке не было и из под коробки мне систему запустить не удалось, только после правки ошибок. Поэтому внедрил по самому минимуму. Остались только реестры. От ИСОГД там только одно название. Поэтому переписывать на XAF было бы не сложно. Вопрос в дальнейшей поддержке...как и с Инметой)

Почему я взялся вообще внедрять) - Вы, наверное, помните Мурманск с тендером на 14 млн на внедрение ИСОГД) Вы нам еще презентацию показывали. Было у нас тут свое местное смутное время и временщики у власти. Сделали все, чтобы выиграла ПТК "СОТО". http://goo.gl/WMf5C5 - вот тут я писал, про этот продукт.
Я уже хотел увольняться, но сменилась власть, изыскали средства и купили мониторинг) Радость моя правда была не долгой. Ну да ладно.

Я обрадовался, когда увидел статью об Инсис.
Какие у меня вопросы:
1. Есть Инмета, есть Инсис. "В конечном счете обе системы сольются полностью" - что это значит? Как это будет выглядеть? Можно ли будет как-то просто мигрировать. Конвертация метаданных или еще что-то.
2. Каковы сроки реализации?
3. Что за лицензия? Надо ли будет платить за переход на Инсис? Потому что, судя по статье, планы наполеоновские. Чуть ли не универсальная ERP с ГИС возможностями. Может будет платная и открытая лицензия, как у многих систем на рынке?
4. Ну и будет ли обновляться Инмета вообще? или останется в текущей стадии?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Сергей Попов



Зарегистрирован: 05.03.2005
Сообщения: 299
Откуда: г. Тольятти - Самара - Копейск

СообщениеДобавлено: Пн 30 Июн 2014 17:27    Заголовок сообщения: Ответить с цитатой

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

_________________
г. Тольятти, г. Самара, ОАО "КУЗНЕЦОВ"
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Gorbach



Зарегистрирован: 19.09.2006
Сообщения: 31
Откуда: Уфа

СообщениеДобавлено: Вт 01 Июл 2014 11:52    Заголовок сообщения: Ответить с цитатой

nawakster писал(а):
Gorbach
А я с Вам согласен на 100%.
Переписать код с нуля - это самое ужасное, что можно придумать. Когда возникают такие мысли обычно перечитываю Спольски http://habrahabr.ru/post/219651/


Ну, если бы Спольски был прав, мы бы все до сих пор писали в MS DOS и на Фортране. Относительно простым рефактрингом можно обойтись пока мы развиваем код в рамках существующей архитектуры. А если сама архитектура является тормозом, то оказывается, что затраты на сопровождение и развитие системы становятся неприемлемыми и правильнее переписать почти всё. Какие-то библиотеки из старых могут использоваться, но по большому счету переписывается практически всё, чтобы как раз развитие системы стало не слишком обременительным. В строительстве Вы не сможете из существующего сарая путем надстроек над ним получить небоскреб как бы строители не доверяли Спольски.

Напротив, в программной индустрии есть архитектурная эмпирика следующего рода: написать новую программу примерно в 4 раза дольше (и сложнее), чем рефакторить существующий код. Но как раз поэтому, если в результате перестройки системы придется переписать более 25% серьезного архитектурного кода, то разработать новую систему на новой архитектуре с нуля будет вполне разумно и даже правильнее, потому что в результате будет создана архитектура, более адекватная текущему и будущему времени при тех же или меньших затратах

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

nawakster писал(а):

Выше написал, почему мысли меня не покидали. Но главные 3 причины:
1. Отсутствие документации и поддержки.

Для меня это неожиданно, потому что мы всегда помогаем заказчикам. Другое дело, если помощь становится уже дорогой, то надо все-таки планировать деньги, - ведь мы не можем все делать за свой счет.
А с Мурманском вообще своя песня: к нам не обращались с задачей внедрения. Ну, раз сами, то сами...
nawakster писал(а):

2. Отсутствие апдейтов уже больше, чем 2 года. Да и до этого, апдейты были чисто косметические. Никаких новых фич.

Апдейтов нет, потому что там нечего апдейтить в рамках принятой архитектуры. Я не стану критиковать сильно наш продукт, но доводы почему сильно развивать её - дорого, есть во множестве. Поэтому и делалась новая архитектура сразу на другой масштабный уровень. Мы не собирались повторять ИнМету. Она решает свои задачи на уровне учреждения - и этого достаточно.
nawakster писал(а):

Я написал пару раз об этом в том году и в этом на суппорт, Власову и вот на форуме http://www.integro.ru/forum/viewtopic.php?t=1386. Ни ответа, ни привета.

Я не хотел бы обсуждать Власова. Но у нас есть множество более оотзывчивых людей. Smile
nawakster писал(а):

Зато в прайсе появилась строчка Лицензия на систему продаётся при условии, что заказчик планирует в дальнейшем внедрение этой системы силами нашей компании или авторизованных партнёров.))

Эта строчка связана совсем с другими причинами. Дело в том, что цена на инструмент у нас очень небольшая и чаще всего ниже себестоимости. Многим покупателям и посредникам кажется, что поэтому система проста, и они сами всё сделают типа как в Word поставить и начать печатать. Обычно некая фирма в каком-то городе пытается стать посредником между нами и неизвестным покупателем. Но мы не хотим, чтобы систему кто-то купил, потратив деньги, а потом некий посредник из торговцев, не зная ни предметную область, ни задачи внедрения, "подставил" покупателя без последующего внедрения. Поэтому мы и требуем, чтобы заказчик сначала узнал всё у задаче, какие дальнейшие затраты на внедрение его ждут, и только после этого покупал, если понимает, что 50тыс. за систему - это только начало перед внедрением за млн. и более. У нас нет задачи всучить ПО, которое без наполнения документами, местными методиками всяких расчетов и т.п. использовать нельзя.
nawakster писал(а):

Я думал вы совсем забили на продукт.

Нет. Просто развитие её сейчас начинается в рамках существующих предметных систем. Если получится исправить архитектурные проблемы, то такие изменения будут. Они, собственно, есть, но обкатываются у нас в Уфе.
nawakster писал(а):

3. У меня первые пару месяцев был шок от Мониторинга. После Ингео я такой подставы не ожидал)) Даже вменямой инструкции по установке не было и из под коробки мне систему запустить не удалось, только после правки ошибок. Поэтому внедрил по самому минимуму. Остались только реестры.

Ну, раз Вы сами решили развиваться, то ничего не поделаешь. Мне кажется, что надо было думать о полноценном внедрении нашими силами, и всё бы получилось быстро и легко. Тем более, Мониторинг. Я вообще первый раз (от Вас) слышу с ним какие-то проблемы.
nawakster писал(а):

От ИСОГД там только одно название.

Дык, и в Постановлении 363 АИС ОГД - это детство. Но Мониторинг-то очень велик. В нем АИС ОГД - 1% от всех функций.
Честно говоря, я не очень понимаю, зачем Вы взялись самостоятельно за такую махину. (А ИСОГД, кстати, это совсем другой термин).
nawakster писал(а):

Поэтому переписывать на XAF было бы не сложно. Вопрос в дальнейшей поддержке...как и с Инметой)

Вот-вот... Smile
nawakster писал(а):

Почему я взялся вообще внедрять) - Вы, наверное, помните Мурманск с тендером на 14 млн на внедрение ИСОГД) Вы нам еще презентацию показывали. Было у нас тут свое местное смутное время и временщики у власти. Сделали все, чтобы выиграла ПТК "СОТО". http://goo.gl/WMf5C5 - вот тут я писал, про этот продукт.

Прочитал. Вам почти невозможно угодить. Smile
nawakster писал(а):

Я уже хотел увольняться, но сменилась власть, изыскали средства и купили мониторинг) Радость моя правда была не долгой. Ну да ладно.

Предметные системы требуют внедрения причем обученными людьми. Вы практически любую крупную предметно-ориентированную систему самостоятельно не внедрите. Это как купить "Боинг" и думать, что сами научитесь его обслуживать и начнете летать... Вы как и все программисты - большой оптимист. Smile

На остальные вопросы, - если позволите, - я отвечу не сегодня, потому что сейчас попал в цейтнот. Отвечу только на п.4

nawakster писал(а):

4. Ну и будет ли обновляться Инмета вообще? или останется в текущей стадии?


ИнМета будет обновляться, но пока не слишком сильно, потому что что-то наши любимые заказчики насели на нас с новыми предметными задачами, которые требуют немалой правки предметного кода, а сильно трогать ядро надо осторожно, потому что всем заказчикам придется всё обновлять. Далеко не все этого хотят: "работает и пусть работает..."
А сопровождать несколько версий ИнМеты тоже опасно и дорого.

С уважением, Вадим
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
SergeyV



Зарегистрирован: 06.06.2014
Сообщения: 20
Откуда: ЦСИ "Интегро"

СообщениеДобавлено: Вт 01 Июл 2014 15:44    Заголовок сообщения: Ответить с цитатой

nawakster писал(а):
Пожелания. мм..
...
3. Удобное администрирование - обещаете.

Удобство – вещь субъективная, поэтому я этого обещания побаиваюсь. Скажете потом, что обещали удобное администрирование, а оно оказалось неудобным. Smile
nawakster писал(а):
4. Удобную среду разработки - С инмета я познал все прелести разработки в блокноте. . На диски(комитет 2 раза мониторинг покупал и содержание дисков отличалось значительно), забыли положить почему-то xmlbuilder. Каша из XML, VBScript, html и SQL без автокомплита и отладки - редкостный мазохизм. Через годик, когда я увидел xmlbuilder - он меня тоже не особо обрадывал. В блокноте мне уже было проще и быстрее.
Если верить статье, то в Инсис я бы познал все прелести разработки - VS, C#, ORM, Linq. Как это выглядит непонятно, но удобство разработки обещаете. Хотелось бы еще реализацию подхода "Model First". Как во всех продвинутых ORM.

Все «прелести разработки в блокноте» познал и я в свое время, так что Вашу боль прекрасно понимаю Smile. А вот «прелести разработки в VS на C# с использованием Linq и ORM» вытекают автоматически из того, что другого кода в ИнСис просто нет. Даже на ExtJs описываются только пользовательские представления, которые изначально генерируются автоматически, поэтому с JavaScript иметь дело практически не придется. Кроме того, у нас уже есть некоторые пробные расширения для VS, так что специфичные для ИнСис средства разработки мы постараемся встроить в VS.
Что касается «Model First» - настолько ли это необходимая вещь? К примеру, в Entity Framework «Code first» подход является более популярным, насколько я понимаю. По сути вы также имеете редактор модели в виде Class Diagram, получаете простые классы C# и несложными манипуляциями делаете их сохраняемыми (persisted). Какие преимущества дает «Model First» – подход? (если мы, конечно, одинаково интерпретируем эти термины).
nawakster писал(а):
5. Интерфейс. У Инметы он практически не настраивается. Я не про отображение данных, а про элементы. Вот например, поле ассоциации - поиск осуществляется с первого введенного символа, из-за этого постоянно подвешивается база. Чего проще, сделать поиск после трех введенных символов, но мне никак.

В ИнМете интерфейс генерируется в runtime и влиять на него можно только через настройки в метаданных. В ИнСис интерфейс генерируется в design time и в случае с ExtJs представляет собой набор классов - представлений, в каждом из которых объявлен перечень контролов для отображения атрибутов объекта. Вы можете открыть код этих классов и поменять расположение контролов или их параметры. Для примера, мы изменили число символов, после которых идет запрос значений выпадающего списка с сервера, с 1 на 5 просто добавлением нескольких символов.
nawakster писал(а):
В Инсис - обещаете ExtJs. Это интересно. Вопрос, конечно, в скорости.

В ИнСис – ExtJs, но он здесь отвечает исключительно за отображение презентационной модели (View Model) в браузере. Поэтому, ничего не мешает даже для отдельных реестров/функций реализовать свой интерфейс на любимом фреймворке (JQuery + JQueryUI, SAP UI и т.д.). Сервер просто реализует некоторый API на базе протокола HTTP и выдает презентационные модели в JSON или XML. Это также позволяет делать не только Web, но и native-интерфейс для операционных систем. Мы например, делали макет интерфейса на WPF.
nawakster писал(а):
А Инсис, думаю, через пару лет допилите до релиза. Но я тогда уже уволюсь, скорей всего)

Пары лет у нас нет – нужно сделать раньше Smile
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
SergeyV



Зарегистрирован: 06.06.2014
Сообщения: 20
Откуда: ЦСИ "Интегро"

СообщениеДобавлено: Вт 01 Июл 2014 16:00    Заголовок сообщения: Ответить с цитатой

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

Тогда получается, что момент изменения версии объекта - это момент, явно указанный пользователем, а в остальном все так же, как я описал раньше. Только вот моя вера в пользователей, увы, не так сильна. Они, конечно, в подавляющем большинстве очень хорошие люди, но ошибки делают часто Smile Типовому пользователю всегда проще изменить значение в поле и ни о чем дальше не заботиться. Т.е. зашел в конкретный тариф 1-го апреля и повысил его, а кнопку отправки предыдущей версии в историю нажать забыл. Лучше бы как-то заранее определить, что изменение определенных параметров объектов - это переход его в новую стадию своего жизненного цикла. Такое изменение должно быть как-то визуально обозначено, чтобы пользователь понимал, что это приведет к довольно серьезным последствиям в системе. Если же нужно просто исправить ошибку, то это тоже отдельный процесс. Я в связи с этим вспоминаю ситуацию а одной сети супермаркетов, где для того, чтобы убрать ошибочно пробитый товар из чека зовут специального менеджера с магическим штрих-кодом и только этот человек может вносить коррективы в чек.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Сергей Попов



Зарегистрирован: 05.03.2005
Сообщения: 299
Откуда: г. Тольятти - Самара - Копейск

СообщениеДобавлено: Ср 02 Июл 2014 10:00    Заголовок сообщения: Ответить с цитатой

SergeyV писал(а):
...Они [пользователи], конечно, в подавляющем большинстве очень хорошие люди, но ошибки делают часто...
Относительно любых ошибок (не только в разрезе историзмов и временизмов) можно выстроить общую теорию, реализовать в ИнСис комплекс механизмов и инструментов, тонкую настройки которых необходимо произвести на этапе внедрения и в дальнейшем эффективно использовать.

Далее моя попытка внести свой вклад в эту теорию:

1. Фоновый контроль (регистрация) всех действий. Это как камеры видеофиксации. Зная, что при необходимости можно поднять всю историю, пользователь будет чуточку осторожнее и требовательнее к себе. Таким образом мы можем не беспокоиться более того чем требуется о преднамеренном вредительстве со стороны пользователя.
Остаются случаи непреднамеренных ошибок ничтожных, средних, важных типов. Другая классификация: единичные и массовые.
Для каждого типа ошибок можно применять соответствующий инструмент предотвращения оных.

2. НИЧТОЖНЫЕ: Акцентировать внимание: "Вы уверены?" Лучше, если пользователь получит дополнительную информацию о характере сомнений системы в его действиях: "Обращаю Ваше внимание, что введённое Вами значение этажности выходит за границы предельных параметров в данной территориальной зоне, и ссылки...".

3. СРЕДНИЕ и УСЛОВНЫЕ: Средние система позволяет допустить, но информирует об этом уполномоченное лицо, которое вправе отменить внесённые изменения и инициировать процесс согласования позиций с оператором. Зная об этом, оператор может в момент внесения изменений дать дополнительное пояснение (внести в систему) или выполнить дополнительные действия (условия), [прикрепить документ - основание]. Выполнение условий может трактоваться системой как снятие подозрения в ошибке.

4. ВАЖНЫЕ: Требующие одобрение ответственного лица. Тот самый случай когда очередь ждёт прихода к кассе сотрудника с мастер-ключом.

5. МАССОВЫЕ. Я их упомянул, но пока ничего не придумал.

И ещё: хочется в отдельный раздел выделить ИСПРАВЛЕНИЕ ОШИБКИ.
Можно так зарегулировать процессы, что исправить ошибку станет многократно сложнее чем допустить её.
Особый случай: ИСПРАВЛЕНИЕ ОШИБКИ в системе с элементами ИСТОРИЗМА.
Для наглядности надо представить два графика с использованием осей ВРЕМЯ и ЗНАЧЕНИЕ.
1 график: ФАКТ. В нём нет ошибки. ЗНАЧЕНИЕ неизменное.
2 график: ОТРАЖЕНИЕ ФАКТА в СИСТЕМЕ: тут есть момент времени t1 - внесение ошибки, и момент времени t2 - исправление ошибки. ЗНАЧЕНИЕ до t1 и после t2 одинаковое, а между ними - ошибочное.
Таким образом для ответа на вопрос: "Какое значение действовало в интервале от t1 до t2" мы используем график 1.
А на вопрос "на основании каких сведений был подготовлен ответ в конкретный момент времени" мы используем график 2.

_________________
г. Тольятти, г. Самара, ОАО "КУЗНЕЦОВ"
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Показать сообщения:   
Начать новую тему   Ответить на тему    Список форумов www.integro.ru -> Перспективы Часовой пояс: GMT + 5
На страницу 1, 2, 3  След.
Страница 1 из 3

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете добавлять приложения в этом форуме
Вы можете скачивать файлы в этом форуме


© phpBB Group
Русская поддержка phpBB