Что такое модификация программного обеспечения

Обновлено: 04.07.2024

Коллеги, кто-нибудь знаком с программным продуктом "1С: Предприятие 8.1"? Вопрос вот в чём. Есть коробочная лицензия на продукт от Фирмы 1С, она прямо запрещает модификацию ПО (изменения кода ПО и содержимого баз данных, КРОМЕ тех, которые вносятся штатными средствами, входящими в состав ПО и описанными в сопроводительной документации. Одна фирма нам предложила на платформе "1С: Предприятие 8.1" разработать под нашу организацию необходимую конфигурацию для учета ТМЦ. Они утверждают, что модификации ПО по вышеуказанной причине не происходит, т.к. меняется лишь конфигурация программы в рамках заданных опций настроек. С другой стороны, в договоре они прописали отчуждение исключительного права на результат такой новой конфигурации. Может, кто-нибудь сталкивался с подобным? Происходит ли на деле модификация ПО, не разрешенная правообладателем, или обычные настройки в рамках обычного использования ПО? Интересует чисто технический аспект, т.к. я не силен в этих компьютерных делах.

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

Ты настоящий Дарт Вейдер (с) Foma

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

Есть коробочная лицензия на продукт от Фирмы 1С, она прямо запрещает модификацию ПО (изменения кода ПО и содержимого баз данных, КРОМЕ тех, которые вносятся штатными средствами, входящими в состав ПО и описанными в сопроводительной документации

А прописали про отчуждение ИП они скорее всего для того, чтобы НДС не было

Не шутите так поверят еще.
Имхо, изначально 1-С, Oracle, SQL и т.п.это программы ЭВМ (среда) с помощью которых конечный пользователь создает базы данных по смыслу 1260ГК, то есть создает систематизированную совокупность материалов. Соответственно если подрядчик вносит изменения в исходный код программы, то это модификация. Если же он производит настройку этой программы, то где же тут модификация? Все действия исключительно в рамках пп.1.1. ст. 1280. Если под каждой такой настройкой понимать модификацию, запаришься на учет принимать новые объекты. Тут скорее возникает вопрос об авторских правах на БД по смыслу п.2 ст.1259, то есть вопрос о творческом характере расположения материалов. Но в любом случае отчуждения искл. права тут не будет, ибо оно изначально у заказчика возникает.
Ну это все теория, к сожалению, не подтвержденная судебной практикой. на практике во избежание недоразумений пишу о работах по техподдержке и адаптации ПО, с перенесением рисков нарушения исключительного права на исполнителя Если он уверяет, что модификации нет, пусть потом и отдувается за все.

login123
Tunec
pavelser
Спасибо! Говорят, 1С-Предприятие - продукт сырой, вот каждый и конфигурирует его под себя, и наши информационщики решили нанять такого "конфигуратора"

Server

"абзацы 2-3 пункта 31 Проекта: Переработка произведения предполагает создание нового (производного) произведения на основе уже существующего. При этом право на переработку произведения как один из способов использования результата интеллектуальной деятельности может быть передано в числе иных правомочий в рамках передачи исключительного права по договору об отчуждении исключительного права в полном объеме (статья 1234 ГК РФ) либо быть предоставлено по лицензионному договору (статья 1235 ГК РФ), а также может перейти по установленным в законе основаниям без заключения договора с правообладателем (статья 1241 ГК РФ).

Частным случаем переработки произведения является модификация программы для ЭВМ или базы данных, то есть любые их изменения , в том числе перевод такой программы или такой базы данных с одного языка программирования на другой, за исключением адаптации, представляющей собой внесение изменений, осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя.

Учитывая, что в результате модификации создается новая программа для ЭВМ или база данных, для их правомерного использования необходимо заключение нового лицензионного договора о предоставлении права использования программы для ЭВМ или базы данных (пункт 3 статьи 1286 ГК РФ)".

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

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

(для справки - 1С - это тоже язык программирования).

перевод такой программы или такой базы данных с одного языка программирования на другой

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

Server
А почему за пределы штатных средств выходить нельзя?
Только потому что праообладатель так захотел?
А если праообладатель перестанет снабжать продукт штатными средствами, или вообще запретит вносить изменения?

На мой взгляд следует отталкиваться от императивности ст. 1280 ГК РФ.
Любую попытку ограничить права лица, правомерно владеющее экземпляром программы для ЭВМ следует считать ничтожной.

Статья 1280. Свободное воспроизведение программ для ЭВМ и баз данных. Декомпилирование программ для ЭВМ

1. Лицо, правомерно владеющее экземпляром программы для ЭВМ или экземпляром базы данных (пользователь), вправе без разрешения автора или иного правообладателя и без выплаты дополнительного вознаграждения:

1) внести в программу для ЭВМ или базу данных изменения исключительно в целях их функционирования на технических средствах пользователя и осуществлять действия, необходимые для функционирования таких программы или базы данных в соответствии с их назначением, в том числе запись и хранение в памяти ЭВМ (одной ЭВМ или одного пользователя сети), а также осуществить исправление явных ошибок, если иное не предусмотрено договором с правообладателем;

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

2. Лицо, правомерно владеющее экземпляром программы для ЭВМ, вправе без согласия правообладателя и без выплаты дополнительного вознаграждения изучать, исследовать или испытывать функционирование такой программы в целях определения идей и принципов, лежащих в основе любого элемента программы для ЭВМ, путем осуществления действий, предусмотренных подпунктом 1 пункта 1 настоящей статьи.

3. Лицо, правомерно владеющее экземпляром программы для ЭВМ, вправе без согласия правообладателя и без выплаты дополнительного вознаграждения воспроизвести и преобразовать объектный код в исходный текст (декомпилировать программу для ЭВМ) или поручить иным лицам осуществить эти действия, если они необходимы для достижения способности к взаимодействию независимо разработанной этим лицом программы для ЭВМ с другими программами, которые могут взаимодействовать с декомпилируемой программой, при соблюдении следующих условий:

1) информация, необходимая для достижения способности к взаимодействию, ранее не была доступна этому лицу из других источников;

2) указанные действия осуществляются в отношении только тех частей декомпилируемой программы для ЭВМ, которые необходимы для достижения способности к взаимодействию;

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

4. Применение положений, предусмотренных настоящей статьей, не должно наносить неоправданный ущерб нормальному использованию программы для ЭВМ или базы данных и не должно ущемлять необоснованным образом законные интересы автора или иного правообладателя.

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

СОДЕРЖАНИЕ

Стратегии

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

Стратегии модернизации

Существуют разные драйверы и стратегии модернизации программного обеспечения:

Модернизация, управляемая архитектурой (ADM) - это инициатива по стандартизации представлений о существующих системах с целью обеспечения общих действий по модернизации, таких как анализ и понимание кода, а также преобразование программного обеспечения.
Подход, ориентированный на бизнес: стратегия модернизации связана с добавленной стоимостью бизнеса в результате модернизации. Это подразумевает определение пересечения критичности приложения для бизнеса с его техническим качеством. Этот подход, продвигаемый Gartner, ставит анализ портфеля приложений (APA) как необходимое условие для принятия решений по модернизации портфеля приложений для измерения состояния программного обеспечения, рисков, сложности и стоимости, обеспечивая понимание сильных и слабых сторон приложений.
Модельно-ориентированная инженерия (MDE) исследуется как подход к обратному проектированию, а затем к прямому проектированию программного кода.
Метод Возрождения для итеративной оценки устаревших систем с технической, деловой и организационной точек зрения.
WMU (Warrants, Maintenance, Upgrade) - это модель для выбора подходящих стратегий обслуживания, основанная на желаемом уровне удовлетворенности клиентов и их влиянии на него.

Управление рисками модернизации

Модернизация программного обеспечения - это рискованный, сложный, длительный и высокоинтеллектуальный процесс, в котором участвует множество заинтересованных сторон. Задачи модернизации программного обеспечения поддерживаются различными инструментами, относящимися к архитектуре, управляемой моделями, от Группы управления объектами и такими процессами, как ISO / IEC 14764: 2006 или Сервис-ориентированная миграция и повторное использование (SMART). Модернизация программного обеспечения подразумевает выполнение различных ручных и автоматизированных задач специализированными специалистами. Инструменты поддерживают задачи участников проекта и помогают организовать совместную работу и упорядочить работу.

Общий подход к управлению модернизацией программного обеспечения, явно учитывающий риски (как технологические, так и бизнес-цели), состоит из:

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

Затраты на модернизацию

Softcalc (Sneed, 1995a) - это модель и инструмент для оценки стоимости входящих запросов на обслуживание, разработанный на основе COCOMO и FPA.
EMEE (Оценка работ по раннему обслуживанию) - это новый подход к быстрой оценке трудозатрат до начала фактического обслуживания.
RENAISSANCE - это метод поддержки эволюции системы, сначала восстанавливая стабильную основу с помощью реинжиниринга, а затем непрерывно улучшая систему потоком постепенных изменений. Подход успешно интегрируется с различными процессами управления проектами.

Проблемы модернизации устаревшего оборудования

Основные проблемы с унаследованной системой включают очень старые системы с отсутствием документации, недостаток малых и средних предприятий / знаний по унаследованным системам и нехватку технологических навыков, в которых были внедрены унаследованные системы. Типичные устаревшие системы существуют более двух десятилетий. Миграция чревата проблемами:

Отсутствие прозрачности для больших портфелей приложений. Крупные ИТ-организации имеют сотни, если не тысячи, программных систем. Технологии и функциональные знания по своей природе распределены, разбавлены и непрозрачны. Отсутствие центральной точки видимости для высшего руководства и архитекторов предприятия не является главной проблемой - сложно принимать решения о модернизации программных систем, не имея необходимых количественных и качественных данных об этих системах в масштабах всего предприятия.
Управление организационными изменениями. Пользователи должны быть переобучены и оснащены для эффективного использования и понимания новых приложений и платформ.
Сосуществование унаследованных и новых систем. Организации с большим количеством унаследованных систем не могут мигрировать сразу. Необходимо принять поэтапный подход к модернизации. Однако это создает свой собственный набор проблем, таких как обеспечение полного охвата бизнеса с хорошо понятными и реализованными дублирующими функциями, дублирование данных; одноразовые системы для объединения устаревших и новых систем, необходимых на промежуточных этапах.
Плохое управление качеством структуры (см. Качество программного обеспечения ), в результате чего модернизированное приложение несет больше проблем с безопасностью, надежностью и ремонтопригодностью, чем исходная система.
Значительные затраты на модернизацию и продолжительность - Модернизация сложной устаревшей критически важной системы может потребовать больших инвестиций, а продолжительность полностью работающей модернизированной системы может исчисляться годами, не говоря уже о непредвиденных неопределенностях в этом процессе.
Обязательства заинтересованных сторон - основные заинтересованные стороны организации должны быть уверены в инвестировании в модернизацию, поскольку выгоды и немедленная окупаемость инвестиций могут быть незаметны по сравнению с вложенными затратами на модернизацию.
Состав программного обеспечения. В наши дни разработчики крайне редко создают 100% оригинальный код для чего-либо, созданного после 2010 года. Они часто используют сторонние и открытые исходные коды, а также программные компоненты для повышения эффективности, скорости и возможности повторного использования. Это создает два риска: 1.) уязвимости в стороннем коде и 2.) риск лицензирования с открытым исходным кодом.

И последнее, но не менее важное: не существует универсального решения, подходящего для всех вариантов модернизации. При наличии множества коммерческих и индивидуальных вариантов модернизации для заказчиков, продавцов и исполнителей критически важно понимать тонкости различных методов модернизации, их наилучшие применимые реализации, пригодность в конкретном контексте и передовые методы, которым следует следовать раньше. выбор правильного подхода к модернизации.

Варианты модернизации

Оценка приложений: определение базового уровня существующего портфеля приложений с использованием аналитики программного обеспечения для понимания работоспособности, качества, состава, сложности программного обеспечения и готовности к облаку для начала сегментации и определения приоритетов приложений для различных вариантов модернизации.
Обнаружение приложений : компоненты приложений сильно переплетены, что подразумевает необходимость понимания сложности и разрешения взаимозависимостей компонентов программного обеспечения.
Миграция: миграция языков (3GL или 4GL), баз данных (устаревшие в РСУБД и одной РСУБД в другую), платформы (из одной ОС в другую), часто с использованием автоматических преобразователей или систем преобразования программ для повышения эффективности. Это быстрый и экономичный способ преобразования устаревших систем.
Миграция в облако: миграция устаревших приложений на облачные платформы, часто с использованием такой методологии, как методология 5 Rs от Gartner для сегментации приложений и определения их приоритетов по различным моделям (Rehost, Refactor, Revise, Rebuild, Replace).
Реинжиниринг: метод перестройки унаследованных приложений на новую технологию или платформу с такой же или расширенной функциональностью - обычно путем принятия сервис-ориентированной архитектуры (SOA). Это наиболее эффективный и гибкий способ преобразования унаследованных приложений. Для этого требуется программный интеллект на уровне приложений с устаревшими системами, которые малоизвестны или документированы.
Повторный хостинг: запуск устаревших приложений без серьезных изменений на другой платформе. Бизнес-логика сохраняется по мере того, как приложение и данные переносятся в открытую среду. Этот вариант требует замены только промежуточного программного обеспечения, оборудования, операционной системы и базы данных. Это часто используется в качестве промежуточного шага для отказа от устаревшего и дорогого оборудования. Наиболее распространенные примеры включают мэйнфреймы приложения которые rehosted на UNIX или Wintel платформы.
Внедрение пакета: замена устаревших приложений, полностью или частично, на стандартное программное обеспечение (COTS), такое как ERP, CRM, SCM, программное обеспечение для выставления счетов и т. Д.

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

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

Миграция программного обеспечения

Миграция программного обеспечения - это процесс перехода от использования одной операционной среды к другой операционной среде, которая в большинстве случаев считается лучшей. Например, переход с Windows NT Server на Windows 2000 Server обычно считается миграцией, поскольку он включает в себя обеспечение использования новых функций, отсутствие необходимости изменения старых настроек и принятие мер для обеспечения того, чтобы текущие приложения продолжали работать в новых. среда. Миграция также может означать переход с Windows NT на операционную систему на основе UNIX (или наоборот). Миграция может включать переход на новое оборудование, новое программное обеспечение или и то, и другое. Миграция может быть мелкомасштабной, например, миграция одной системы, или крупномасштабной, включающей множество систем, новых приложений или измененную сеть.

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

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

Перенос установленного программного обеспечения со старого ПК на новый можно выполнить с помощью инструмента миграции программного обеспечения. Миграция также используется для обозначения процесса перемещения данных с одного устройства хранения на другое.

Статьи, статьи и книги

Создание многоразового программного обеспечения

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

Модернизация с управлением рисками

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

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

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

Подходы к настройке и адаптации функциональности ITSM-платформы

Можно выделить шесть основных способов, с помощью которых путем конфигурации и адаптации готовое приложение можно превратить в требуемое решение.

Модификация структуры метаданных. В этом случае структура готовой базы данных меняется таким образом, чтобы она лучше соответствовала требованиям, предъявляемым к данным в конкретной организации: добавление новых таблиц, изменение типов данных, установка атрибутов данных.

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

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

Модификация программного кода. Способ предусматривает прямую трансформацию исходного кода для добавления или изменения функциональности системы. Это может быть сделано производителем или пользователем и является самым дорогим и технически сложным методом.

Последствия конфигурирования и адаптации

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

Рост операционных расходов и расходов на сопровождение зависит от сложности конфигурации и адаптации. Чем более существенные изменения вносятся в стандартную платформу ITSM, тем больше будут расходы на сопровождение на протяжении всего жизненного цикла продукта. Также нельзя игнорировать возникающую зависимость от качества поддержки адаптированного решения со стороны разработчиков уникального решения.

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

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

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

Когда необходимы изменения готового решения?

Предположим, что средние затраты на изменения составят: а) на реализацию одного требования с помощью конфигурации— 50 долл, что равняется примерно 2-4 часам работы администратора системы; б) на реализацию одного требования с помощью адаптации— 1 тыс. долл., что составляет примерно 1-2 дня работы разработчика системы. В таком случае, если 20 требований можно на 50% выполнить с помощью конфигурации, а на 50% с помощью адаптации, то вы можете добавить к общей сумме 500 долл. за изменения путем конфигурации и 10 тыс. долл. за изменения путем адаптации. Если у продукта 20 пользователей, и в течение первого года нет необходимости в дальнейших изменениях, то затраты за первый год (исключая расходы на услуги реализации) составят 50500 долл. против 40 тыс. Это на 25% больше, чем если бы готовое решение изначально соответствовало всем требованиям. Кроме того, при отсутствии должного управления, по мере увеличения срока использования продукта те изменения, которые внесены в результате его адаптации, могут вызвать экспоненциальный рост расходов.

ITIL как средство стандартизации

Решения, построенные по принципам ITIL, обладают следующими возможностями:

Изначальная интеграция всех основных процессов ITIL: управление инцидентами, изменениями, задачами, конфигурациями и сервисами. Процессы могут реализовываться поэтапно или развертываться в рамках полной инсталляции пакета, что избавляет от необходимости покупать дополнительно отдельные ITSM-модули.

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

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

Рисунок. Интеграционная архитектура assyst

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

Возможности assyst по интеграции и обмену данными обеспечиваются благодаря специализированным модулям, адаптерам, коллекторам, шлюзам, позволяющим интегрировать решение IT Service Management assyst с любым внешним приложением или источником данных (см. рис.). Интеграционная платформа позволяет организовать любой способ обмена данными: одно- и двунаправленный, событийный, по расписанию, от самых простых вариантов запуска внешних приложений до глубокой интеграции приложений с помощью встроенного API. Assyst позволяет обмениваться релевантной информацией с другими ITSM-системами, внешними системами мониторинга и сбора информации об ИТ-инфраструктуре.

Особенности assyst

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

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

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

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

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

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

Общие принципы правовой защиты программного обеспечения

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

Что показывает анализ судебной практики?

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

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

Камень преткновения - процедура госрегистрации и объем свидетельства

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

Как защитить отдельные версии программного обеспечения?

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

Читайте также: