 |
Используемая СУБД. Функциональные критерии Готовая «коробочная» система или (полу)заказная разработка. Конструктор типа «сделай сам» или готовая прикладная система
|
|
|
|
Используемая СУБД
Собственно, очевидных лидеров тут два — MS SQL Server и Oracle. Практически все не-лотусовские системы, представленные на рынке, используют MS SQL. Некоторые умеют также работать с Oracle (скажем, «Дело»). Системы, ориентированные исключительно на Oracle, мне неизвестны.
Правда, имеется также класс систем, использующих собственные хранилища документов. Как правило, они выросли из некоторых информационно-поисковых систем с большой историей (скажем, «Евфрат» от Cognitive). Свои форматы хранилищ используют также «большие» западные системы — Documentum, HB5 (ex-DocsOpen).
Использование стандартных СУБД является явным плюсом с точки зрения сопровождаемости и масштабируемости системы и простоты ее интеграции в корпоративную IT-инфрастуктуру. Хотя собственное хранилище также обладает некоторыми плюсами: не требуется дополнительно покупать лицензии на СУБД, а с точки зрения администрирования система выступает как единый «черный ящик».
Функциональные критерии Готовая «коробочная» система или (полу)заказная разработка
Это отличие определяется не столько декларациями поставщика, сколько множеством объективных факторов — функциональной полнотой системы, качеством дистрибутива, качеством и объемом документации и др. То есть, в конечном счете, может ли система быть установлена и внедрена силами «типичного» заказчика без участия программистов фирмы-поставщика. Единственным критерием тут является практика — количество заказчиков, самостоятельно установивших и эксплуатирующих систему.
Известно, что превращение проекта (заказной системы) в продукт (коробочную версию) обходится примерно втрое дороже, чем сама разработка, — такова стоимость необходимой функциональной доработки, качественного тестирования, пакетирования дистрибутива, написания документации и других мероприятий, необходимых для выпуска продукта.
|
|
|
Но типичной является ситуация, когда фирма сделала конкретную прикладную систему в дружественной организации Х, затем, переписав треть кода, внедрила ее в организации Y, затем, доделав ее еще немного и внедрив в организации Z, вышла с нею на рынок. Такая система, скорее всего, долго будет нуждаться в существенной адаптации (включающей модификацию кода и документации системы) под каждого нового заказчика. Процесс ее внедрения является чем-то промежуточным между собственно внедрением и заказной разработкой (поэтому мы и называем ее полузаказной).
Плюсы и минусы тут очевидны: с одной стороны, возможность учесть нюансы бизнес-процессов заказчика, с другой — непредсказуемость результата, как с любой заказной разработкой, и, как правило, более высокая суммарная стоимость внедрения.
Кроме того, с такими системами, существующими в единичных и слегка различающихся экземплярах, обычно возникает проблема сопровождения и развития. Зачастую разработчики не выпускают новых версий, а если выпускают, то они плохо совместимы с предыдущими, и переход на них является далеко не простым занятием. Из-за этого не только теряется возможность развития системы, но и возникает риск отстать от технического прогресса и получить проблемы с эксплуатацией старой системы на новых компьютерах, с подключением периферии и др.
Конструктор типа «сделай сам» или готовая прикладная система
Системы типа конструкторов позволяют разрабатывать свои формы документов и отчетных форм, справочники, процедуры их обработки и др., предоставляя для этого более мощный инструментарий, нежели « низкоуровневые» средства разработки.
В основе каждого такого конструктора лежит некоторая «метамодель», определяющая, с одной стороны, класс систем, которые собираются на нем легко и быстро, а с другой — границы его применимости.
|
|
|
Но в любом случае, прежде чем начать эксплуатировать систему на базе конструктора, ее нужно спроектировать и реализовать. При этом, как правило, необходимо участие программистов, так как процедуры обычно пишутся на каком-либо языке — собственном (встроенном) или стандартном (сейчас обычно на VB). Однако нет никакой гарантии, что в процессе реализации вы не наткнетесь на трудно преодолимые ограничения конструктора. В противоположность этому прикладные системы уже имеют встроенный и готовый к использованию функционал и практически не нуждаются в участии программистов для того, чтобы начинать эксплуатацию.
Их различие, впрочем, не является абсолютно жестким, так как почти все конструкторы имеют какие-то изначально запрограммированные на них конфигурации, которые можно рассматривать как прикладные системы, а все готовые прикладные системы имеют определенные возможности настройки и расширения функционала. Вопрос — в соотношении объема базового и прикладного функционала в предлагаемой системе.
Тем не менее водораздел между ними, как правило, достаточно четкий. Если при демонстрации системы вы, к примеру, спрашиваете: как осуществляется контроль отправки исходящих документов нашей экспедицией? — и вам показывают как, — вы имеете дело с прикладной системой. А если вам начинают говорить, что это можно легко запрограммировать, для этого достаточно добавить туда-то такое-то поле и т. д., — вы имеете дело с конструктором.
И это понятно — гибкость и универсальность нередко вступают в противоречие с прикладной функциональностью. Это противоречие может сниматься при очень высоком уровне развития. Скажем, в классе бухгалтерских систем для «1С: Предприятие» оно уже снято. Этот пакет, с одной стороны, является мощным конструктором, а с другой — конкретной прикладной системой, функциональность которой описана в типовой конфигурации и успешно используется в неизменном виде большинством пользователей.
Кстати, Lotus можно рассматривать именно как такой конструктор, а все лотусовские системы — как надстройки (конфигурации).
|
|
|
Заметим, что именно засилье конструкторов и полузаказных систем на рынке не позволяет составить пресловутую табличку сравнительного анализа систем, так как для систем класса конструкторов почти в любую клеточку правомерно ставить плюсик — «можно запрограммировать». А какова при этом будет цена вопроса, особенно если нужно запрограммировать не только одну конкретную функцию, а их тесно взаимодействующую совокупность, — непонятно….
Плюсы и минусы выбора между конструктором и прикладной системой очевидны. Если вам нужно что-то нестандартное, не реализованное в функционале имеющихся готовых систем, или вам хочется «поиграться» (то есть занять свой персонал внутренней разработкой и настройкой системы или под это дело получить дополнительные ресурсы) — преимущества имеет конструктор. Если нужно быстро внедрять — то очевидные преимущества имеет готовая прикладная система с устраивающей вас функциональностью.
С точки зрения рисков — на конструкторе больше риск вообще не получить результата, а у готовой системы — упереться в границы ее функционала при развитии организации или увеличении масштабов внедрения. С финансовой точки зрения — на рынке имеются как «бюджетные» отечественные конструкторы cо стоимостью лицензии от десятков до сотен долларов, так и очень дорогие импортные VIP-конструкторы (тот же Documentum с лицензиями от $1000 на одного пользователя), предоставляющие неограниченные перспективы удовлетворения материальных притязаний заинтересованных лиц.
Лицензии на прикладные системы обычно обходятся в несколько сотен долларов на одного пользователя. Правда, поставщики, как правило, предлагают дополнительные услуги по обследованию, внедрению и обучению, которые позволяют увеличить стоимость проекта в разы и, соответственно, тоже создать приличную базу для удовлетворения материальных интересов.
23. Понятие искусственного интеллекта.
Иску́ сственный интелле́ кт — наука и технология создания интеллектуальных машин, особенно интеллектуальных компьютерных программ. ИИ связан со сходной задачей использования компьютеров для понимания человеческого интеллекта, но не обязательно ограничивается биологически правдоподобными методами.
|
|
|
