Общесистемные критерии качества. Программное обеспечение ИС

[ModeratorGorbi]

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

С уважением, Вадим

[ModeratorChe]

Уважаемые коллеги!
Вот мои предложения по первой версии общесистемных критериев
(я их называю технологические).
Как я писал в общей теме, критери могут быть
a. Бинарный – да 0, нет-10
b. Бальный от 0 до 10, определяемый полностью экспертным путем (от них надо уходить)
c. Балльный (от 1 до 10), но установлен набор функциональных возможностей, которые агрегированы в критерий и степень их проработки в качестве рекомендаций к членам комиссии

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

С уважением, Андрей Чернов.

Используются следующие составные критерии, соответствующие группам функций
• Ввод и редактирование объектов
• Поиск и анализ
• Формирование выходной документации
• Защита и разграничение прав доступа
• Ведение истории изменений и аудита
• Информационный обмен
• Возможности базовой ГИС
• Интернет версия
• Степень открытости системы
• Общее быстродействие системы
• Моделирование, оценка и прогноз
• Иные критерии

Ввод и редактирование объектов

От 1 до 5
• Поддержка пространственных операций пересечения, объединения вычитания и пространственных запросов.
• Совместный ввод и редактирование графической и семантической составляющей объектов.
• Присвоение единых идентификаторов, контроль их уникальности
• Хранение графических данных в промышленных СУБД.
• Клиент-серверный одновременный ввод и редактирование объектов без коллизий по «захвату».
От 6 до 10
• Ведение централизованно изменяемых данных (классификаторов, тезаурусов, правил проверки корректности поставляемых данных, описания систем координат, и т.д.).
• Ввод/редактирование пространственных объектов с поддержкой межслойного топологического редактирования.
• Проверка ссылочной целостности при вводе/удалении/изменении графической и семантической составляющей. Выполнение автоматического контроля данных по централизованным правилам (взаимного положения объектов, значений атрибутов, поиск «висячих» узлов и пр.).
• Ограничение изменений в пространственных и реестровых объектов только в рамках технологических процессов
• Ведение базы метаданных об информационных ресурсах системы согласно соответствующим стандартам ISO

Поиск и анализ

От 1 до 5
• Поиск по внедренным в систему шаблонам
• Поиск по одному или нескольким полям и реквизитам, выбираемым пользователем
• Поиск по интерактивно формируемому запросу пользователем (конструктор запросов) с использованием справочников и связанных таблиц
• Экспорт результатов поиска во внешние файлы, задавание результатов для показа и экспорта.
• Контекстный поиск при выборе значений из справочника
От 6 до 10
• Совместный поиск по графической и семантической составляющим (Поддержка SpatialSQL)
• Поиск по запросам на естественном языке среди нескольких классов объектов
• Возможность пользователя встраивания собственных шаблонов поиска на основе интерактивно формируемых условий
• Индивидуальная настройка критериев и списка шаблонов поиска в зависимости от рабочего места и группы пользователей
• Интерактивный конструктор пространственно-семантических запросов.

Формирование выходной документации

От 1 до 5
• Отчеты по определенному нормативными документами списку
• Отчеты, включающие фрагменты графической и семантической составляющих по объекту
• Создание и редактирование шаблонов отчетов.
• Создание чертежей в соответствии с ГОСТ, СНИП
От 6 до 10
• Наличие и функциональность конструктора отчетов
• Интерактивное создание сводных отчетов (списки, статистика, суммарные отчеты с промежуточными итогами).
• Автоматическая регистрация выходных документов в системе.

Защита и разграничение прав доступа

От 1 до 5
• Функции резервного копирования и восстановления системы администратором (в используемом варианте СУБД).
• Разграничение прав доступа групп пользователей на просмотр/изменение объектов.
• Защита от взлома и несанкционированного копирования.
• Протоколирование действий пользователей.
От 6 до 10
• Поддержка различных статусов (состояний) объектов (проектируемый, действующий, архивный и пр.), разграничение прав доступа по статусам, определение обязательных полей и иных ограничений в зависимости от состояния.
• Разграничение прав доступа групп пользователей на отдельные поля и реквизиты объектов
• Разграничение прав доступа групп пользователей на выполнение функций.
• Поддержка списка закрепленных за пользователем выполняемых функций в технологических процессах.

Ведение истории изменений и аудита


1 балл – ведется лог-файл аудита изменений (кто, когда изменил)
От 2 до 4 баллов
• Ведется полная история изменений для выбранных классов реестровых объектов (все значения семантических полей), просмотр предыдущих состояний.
• Восстановление предыдущего состояния объекта.
• Ведение истории графической части объектов, просмотр и воостановление
От 5 до 10
• Полная история изменений для выбранных классов реестровых объектов и связанных объектов, просмотр предыдущих состояний.
• Массовый откат на заданную дату изменения для выбранного класса объектов, выбранной области для конкретного пользователя с возможностью отмены отката (внутри одной транзакции).
• Использование исторических данных в аналитических отчетах, выборках и шаблонах поиска наравне с актуальными.

Информационный обмен

От 1 до 5
• Импорт-экспорт в популярных обменных ГИС-форматах (GML,MIF/MID,Shape,dxf)
• Наличие внутреннего открытого описанного формата информационного обмена между экземплярами системы, средства импорта-экспорта
• Наличие средств интерактивного заполнения информации в обменном формате (ручной ввод данных).
От 6 до 10
• Поддержка распределенной среды функционирования системы в режиме offline- репликации (передача только изменений), контроль коллизий.
• Функционирование в режиме центральный узел – локальные узлы с верификацией локальных изменений на центральном узле.
• Экспорт данных по подписке.
• Импорт данных через промежуточный буфер обмена с возможностью контроля установленных соответствий (поиск дубликатов, контроль неверно введенных данных).

Возможности базовой ГИС

В этом пункте указываются возможности блока обработки пространственной информации, используемой в программном обеспечении. Не дублируют соответствующие пункты из других разделов критериев.
От 1 до 5
• Создание тематических карт различными методами (индивидуальные значения, диапазоны, плотность точек и др.)
• Использование в качестве подложки произвольного количества геопривязанных растровых изображений.
• Индивидуальная настройка для пользователей рабочего окружения (набор и порядок показываемых слоев, условные знаки, иные элементы).
• Отображение объектов, удовлетворяющее требованиям «Условные знаки топографических планов масштабов 1:500-1:5000».
• Подключение внешних данных других ГИС без необходимости импорта (показ внешних данных из различных источников).
От 6 до 10
• Наличие и функциональность модуля обработки геодезических измерений.
• Построение и анализ ЦМР.
• Работа с 3D-моделями (рельеф + здания) для обеспечения высотного регулирования, просмотр данных в режиме «произвольного полета», создание полноценных 3D-моделей.
• Санкционированный доступ к растровому архиву изображений с ограничениями по степени секретности (для хранения и отображения растрового архива топопланов).
• Наличие и функции модулей автоматического ввода пространственных объектов с растровых оригиналов.
• Возможность выбора базовой инструментальной ГИС без существенного изменения функциональности.

Интернет версия

Под интернет-версией подразумевается модуль, клиентская часть которого работает в стандартном браузере без необходимости загрузки дополнительных Active-X плагинов с сервера (за исключением Flash-компонентов). Серверная часть функционирует под управлением интернет-серверов, между клиентом и сервером может стоять произвольное количество прокси-серверов.
От 1 до 5
• Функции просмотра, поиска данных, навигация по карте.
• Выдача сведений об основных реестровых объектах.
• Автоматическое обновление данных в интернет-версии при изменении данных в основной базе данных.
• Высокая скорость отображения пространственных данных при одновременной работе Нескольких (5-10) пользователей (оценивается экспертно).
• Поддержка WMS-стандарта
От 6 до 10
• Функционирование Интернет-версии на единой базе данных с основной версией с обеспечением защиты данных или наличие средств фонового online копирования изменений из основной базы данных.
• Вывод информации о состояния технологических процессов (информирование о прохождении заявки…).
• Ввод пользователем собственных пользовательских слоев из векторных объектов (точечных линейных, полигональных), сохранение на сервере, возможность ведения модерируемых пользовательских слоев.
• Поддержка WFS-стандарта
• Представление информации из базы метаданных об информационных ресурсах системы
• Реализация получения платных градостроительных справок (в т.ч. система оплаты)

Степень открытости

Оценивается возможность доработки системы сторонними организациями при использовании стандартных технологий программирования.
0 баллов – программное обеспечение закрыто
От 1 до 5 баллов
• возможность изменения шаблонов выходных документов
• есть описание внутренней структуры таблиц, полей и связей в базе данных
• возможность добавления/удаления полей таблиц базы данных, добавление справочников и ссылок на них без перепрограммирования клиентской части
• возможность добавления собственных отчетов в клиентскую часть
• наличие API для доступа к основным функциям системы
От 6 до 10 баллов
• наличие и функциональность конструктора отчетов, карточек шаблонов поиска и карточек объектов
• доступность системы в исходных кодах (какая часть системы доступна)
• возможность изменения клиентской и серверных частей, интерфейса пользователя, переопределения поведения системы (отклик и обработка событий).
• руководство программиста с примерами использования, работающие примеры расширений

Общее быстродействие системы

• Скорость отображения пространственной информации на дисплее (0.1-0.5 секунд – очень высокая скорость 0.5-1 секунда – высокая 1-3 секунды – средняя, 3-5 секунд – низкая). Скорость высчитывается при отображение фрагмента цифрового плана масштаба 1:500 в соответствующем масштабе.
• Скорость сохранения изменений на сервере для объектов семантической базы данных (5-10 изменений в семантических полях объекта и связанных объектов) (0.1-0.5 секунд – очень высокая скорость 0.5-1 секунда – высокая 1-3 секунды – средняя, 3-5 секунд – низкая).
• Скорость сохранения изменений на сервере для объектов графической базы данных (0.1-0.2 секунды – очень высокая, 0.2-0.5 секунд – высокая, 0.5-1 секунда – средняя, 1-3 секунды – низкая).
• Скорость поиска объектов по критериям (шаблонам поиска) – для запроса, возвращающего ответ из 50-70 записей из общего числа объектов 1000-2000 (0.1-0.2 секунды – очень высокая, 0.2-0.5 секунд – высокая, 0.5-1 секунда – средняя, 1-3 секунды – низкая).

Моделирование, оценка и прогноз
???

Иные критерии

Масштабируемость системы – оценивается экспертным путем.
???

[BWash]

Здравствуйте, уважаемые посетители форума!

Хотелось бы задать вопрос г-ну ModeratorChe по поводу размещенного им списка критериев.

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

И еще. Например, небольшая АИС ОГД, в объеме постановления 363, сделана на базе Oracle и содержит, таким образом, все развитые средства этого продукта. Неужели такое разнообразие системных функций может перекрыть наличие в другой АИС ОГД, пусть и менее "навороченной", подсистемы, автоматизирующий весь процесс ведения адресного реестра города, причем с учетом технологических процессов всего муниципалитета!?


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

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

На этих вопросах пока закончу ввиду отсутствия времени.

[ModeratorChe]

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

Ваши вопросы во-многом вызваны особенностью общения в форуме.
Представленные общесистемные критерии - это "вторая часть" моего выступления.
Первая - viewtopic.php?f=6&t=7#p19
В ней я попытался объяснить , как и что оценивается.
Здесь давайте еще раз проговорим основные тонкие моменты.

1) Общесистемные критерии дополняют предметно ориентированные. Именно в предметно-ориентированных критериях будут описаны "приемка графических данных от изыскательских организаций" и прочее. Этим первой скрипкой занимается Горбачев, и я и вы давайте критиковать или дополнять. Пусть предметные функции имеют больший приоритет, это нормально.

2) Вы говорите - как сравнивать разные СУБД, как сравнивать быстродействие и прочее. Это ведь сложно, да? Но ведь это надо сделать. Нужны какие-то инварианты. И единственный путь такой.
Участник смотра ИСОГД определяет сам конфигурацию общесистемного ПО, технических средств, набор своих модулей , для которых он описывает возможности. На этом же наборе он демонстрирует ПО на смотре.
Что является сдерживающим фактором в аппетитах? - стоимость внедрения проекта.
Стоимость нужно считать не отдельно ПО для ИСОГД , а всего проекта, со всеми компами, СУБД, ОС и прочее.
Вот тогда и будет баланс, и будет оптимальная конфигурация (ведь нормальные айтишники подбирают конфигурацию к ПО), туда же внутрь уйдут все вопросы с использованием вендорного или открытого ПО.

3) Вы пишете "А где взять данные, причем такие, которые могли бы быть залиты во все сравниваемые АИС ОГД, учитывая разнообразие форматов хранения данных внутри различных АИС ОГД? " для выявления быстродействия системы.

Ну давайте думать и решать.
Например, для скорости графического отображения всем участникам выдается геопривязанный планшет городской застройки масштаба 1:500 в растровом виде. Цифруй как хочешь. Уминай в свою структуру БД. А мы посмотрим, во-первых, насколько отображение планшета будет соответствовать условным знакам, во-вторых, - сколько времени потребуется на отображение этого планшета на экране, а в-третьих, - сколько времени надо на ввод или редактирование графического объекта, учитывая все триггеры, которые поставлены на ссылочную целостность.
Думаете, не инвариант?

Предметные критерии надо разрабатывать одновременно с общесистемными.

С уважением, Андрей Чернов.

[BWash]

Добрый день!

Попробую развить свою мысль и поразмышлять над данными мне г-ном ModeratorChe ответами.

Вы говорите, что нужно сравнивать системы как по предметным, так и по системным критериям. Хорошо. Понятно, что как предметных, так и системных критериев довольно много. Чтобы выбрать лучшую АИС ОГД нужно иметь функцию на всем наборе оценок, значение которой и будет отражать "качество" АИС ОГД. Также понятно, что разные "качества" АИС ОГД (в смысле удовлетворения различных предметных, системных и прочих требований) часто взаимоисключающие. Очевидно, что простая как "веник" система будет просто летать, её будет просто администрировать и т.п.

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

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

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

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

Что если таких наборов несколько, как по составу собственно включенных модулей АИС ОГД, так и по набору используемого системного ПО (СУБД, ОС, иные системные средства)? Для каждого такого набора производитель АИС ОГД должен провести испытания? Не кажется ли Вам, что затраты производителя на оценку этих параметров неоправданно высоки по сравнению с тем, какой вес эти параметры имеют для лица, принимающего решение о покупке той или иной АИС ОГД? К чему это?

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

[ModeratorChe]

Здравствуйте, Bwash.

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

Давайте опять думать.

1) если Вы посмотрите первоначальную идею ГИС-ассоциации, то она такая: смотр проектов устраивают в виде конкурса, где выставляются оценки по каждому разделу, а потом оценки суммируются с весами и распределяются места.
Гипотетически - вот Вам функция. Типа как "первое приближение".

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

Делайте, если хотите, свои приоритеты, забивайте на некоторые, некоторые выставляйте в качестве ограничений, как Вы предлагаете.
Ясен пень, глобальная задача - не медальки на шею повесить, а через смотр определить требования к ИСОГД, помочь Заказчику в выборе и подсказать производителям - куда им развивать свои системы.

Что если таких наборов несколько, как по составу собственно включенных модулей АИС ОГД, так и по набору используемого системного ПО (СУБД, ОС, иные системные средства)? Для каждого такого набора производитель АИС ОГД должен провести испытания? Не кажется ли Вам, что затраты производителя на оценку этих параметров неоправданно высоки по сравнению с тем, какой вес эти параметры имеют для лица, принимающего решение о покупке той или иной АИС ОГД? К чему это?

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

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

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

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

С уважением, Андрей Чернов.

[BWash]

Добрый день!

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

Делайте, если хотите, свои приоритеты, забивайте на некоторые, некоторые выставляйте в качестве ограничений, как Вы предлагаете.
Ясен пень, глобальная задача - не медальки на шею повесить, а через смотр определить требования к ИСОГД, помочь Заказчику в выборе и подсказать производителям - куда им развивать свои системы.

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

Вы говорите:

Предметными критериями во-первых, легче жонглировать, чем системными

А заполнение плюсиками огромного перечня строк с системными возможностями продукта - это не жонглирование!? Это то же самое шоу, направленное на то, чтобы запутать заказчика. Я могу взять навороченную СУБД за основу и вписать все её возможности в эту таблицу. Но при этом сами предметные функции я могу реализовать далеко не лучшим образом. Ввиду того, что перечень системных критериев очень развернутый и большой, у покупателя сложится ощущение, что система много чего позволяет, хотя все эти возможности на деле - просто возможности СУБД. Еще не факт, что все они как-то отражаются на предметном уровне.

Теперь по открытости:

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

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

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

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

Абсолютно согласен. Вот только не должны они давлеть над функциональными характеристиками АИС ОГД.

[ModeratorChe]

Здравствуйте, BWash.

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

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

Нет, Вы не можете взять навороченную СУБД и вписать ее возможности, поставив все плюсы.
Какую СУБД? Я неплохо знаю MS SQL, Oracle, хуже остальные, но в принципе, представляю возможности. Говорите, какую.

В моем списке процентов 5-10 - "чистые" возможности СУБД (не забудьте, стоимость ограничивает аппетиты!). Еще 15-20% - возможности СУБД помогают реализовать, но их еще на клиенте надо запрограммировать по умному. Предлагаемые мною критерии сформулированы именно на такую реализацию.

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

Я за открытость. Главный аргумент - такова тенденция развития современного ПО, как я ее понимаю. Вы вольны придерживаться другой точки зрения.

С уважением, Андрей Чернов.

[BWash]

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

Попробую ответить.

Мне кажется, спор немного вырождается и уже просто чтобы поспорить.
Я не до конца понимаю, какая у Вас позиция, что вы хотите.
Отменить системные критерии, оставив только предметные? Я сильно против.
Упростить системные критерии для ИСОГД "малых городов"? - ну давайте сделаем, предложите.
Убедить меня и всех, что предметные критерии - главное? Так ведь я согласен изначально. Просто я взял и написал другой раздел.

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

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

Во-вторых, я не сторонник отменять системные критерии. Я лишь за то, чтобы говорить о них на более крупном уровне, не вдаваясь в технические детали, понятные только специалистам по СУБД, ГИС и т.д. и .т.п. По крайней мере, на данный момент. Они на сегодня не являются определяющими в реальной работе АИС ОГД в УАиГ (как мы с Вами уже согласились) . Например, такие характеристики как "Полная история изменений для выбранных классов реестровых объектов и связанных объектов, просмотр предыдущих состояний, Массовый откат на заданную дату изменения для выбранного класса объектов..." могут совершенно не требоваться для некоторых классов объектов, участвующих в АИС ОГД. А для каких-то классов они крайне важны. Как можно говорить о необхдимости таких характеристик для АИС ОГД, не говоря о каких конкретно классах идет речь? Мы вообще знаем эти классы? Это ведь целая модель городской территории и процессов, связанных с её развитием. Никто пока эту модель не описал. На мой взгляд, даже сам перечень предметных критериев многим пока не понятен (об этом свидетельствует хотя бы то, что конкретных аппеляций и вопросов к их составу практически не было; все либо пытаются дополнить их, либо сказать, что они отражают состав АИС "Мониторинг") Получается, что мы тогда говорим о системных характеристиках АИС ОГД, необходимость которых вообще не очевидна. Это как наличие гироскопа в автомобиле. Вертикаль-то он показывает, все хорошо, но зачем это при управлении автомобилем!? Я, естественно, говорю не о всем перечне предложенных Вами характеристик. Некоторые вполне понятны.

Тут конечно Вы можете возразить, что "сейчас эта детализация не первична", но потом она обязательно потребуется. Согласен. Только я вот чего опасаюсь. Люди, увлеченные различными "фишками" СУБД, ГИС, ОС и т.п., при этом не столкнувшиеся реально с тем огромным числом проблем, которые реально возникают при внедрении АИС ОГД и не имеют никакого отношения к системным параметрам, вообружатся Вашим перечнем критериев и начнут сравнивать с пристрастием различные АИС ОГД именно по нему. Предметный перечень-то не детализирован еще, да и не быстрый это процесс, так как сама предметная область непонятна. Потом эти люди вобъют свое виденье в головы заказчикам в лице руководителей УАиГ и городских администраций. А бороться с этим придется внедренцам; объяснять, что отсутствие развитой системы историзма не накладывает крест на работу АИС ОГД в городе, что можно с успехом отправлять объекты в архив и пользоваться им, написав предварительно четкий регламент работы.

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

Ну и о частностях.

Нет, Вы не можете взять навороченную СУБД и вписать ее возможности, поставив все плюсы.
Какую СУБД? Я неплохо знаю MS SQL, Oracle, хуже остальные, но в принципе, представляю возможности. Говорите, какую.

А как же SpatialSQL? Это не характеристика СУБД? По крайней мере, разве я не могу поставить плюс напротив этого пункта, если СУБД, в которой я храню данные, поддерживат SpatialSQL?
А поиск на естественном языке? Или Вы предполагаете, что кто-то из производителей АИС ОГД возмется собственными силами решать задачу, над которой вот уже более полувека бьются мировые ученые?

В моем списке процентов 5-10 - "чистые" возможности СУБД (не забудьте, стоимость ограничивает аппетиты!). Еще 15-20% - возможности СУБД помогают реализовать, но их еще на клиенте надо запрограммировать по умному. Предлагаемые мною критерии сформулированы именно на такую реализацию.

Я говорил не только о СУБД, а обо всем ПО, которое используется в качестве базы для АИС ОГД.

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

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

Я за открытость. Главный аргумент - такова тенденция развития современного ПО, как я ее понимаю. Вы вольны придерживаться другой точки зрения.

Я тоже, только вопрос за какую?

[xerbrus]

XVII370.1зренBettИллюJewePresПавлWCNoMichFablSony5534NestМирзGlob(флеSwisJuliПершанглVisuPrep
КончСодестудДумбPenhStVaсербCharOrgaCaudОдноLatiфабрYorkGezaHarrByreПалапансВереRogeоднасерт
blonКрукColuКолопостDizzРазуПехоSergсигнtortSelaSanaиллюGeorPariFernтрадRafaCharDoroАндрAmid
MeriBattOrbiMiguMicrGianПолиGeorдопоYakuMcKiзийдWindSwarKarlErleChriсекрКочнIsabвойнWindLope
ArtsApplArtsZoneкольпрозXVIIXVIIКривРазмПетрHowaЕлисDolbWinxMusiMiniFyodChriAlfrTribЭкстGeta
Dalv1950кувшPCIeBERNНизоHitaINTEBookJeffBookКитаСЕ081000OlmeMist1609SlimSKODбайдизгиинстsacr
ChatNighприскамниздемагнРазмГиндWindJeweTratOregсертPumaAdvaJameLindЗверЛитРCaugЛугаMayhразл
ЛитРЕвгеMaryJackТравцеляЧайкШервПушкpunkКоблПаулСценВахтEuroавторассБелюПескавто`ИнтstonПерш
автоМинаОрлоавтоStonчитаофицРуруавтоСмирошибМелеAllaЧукоСторHorsАргоНаумMensStepМареPCIePCIe
PCIewwwc0610СтреВиноКаабAdobдеклПромхудоФормBarbБазиtuchkasXVIIпарт