Rational Unified Process ( RUP ) – одна из лучших методологий разработки программного обеспечения, созданная в компании Rational Software . Основываясь на опыте многих успешных программных проектов, Унифицированный процесс позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки. Одним из основных столпов, на которые опирается RUP , является процесс создания моделей при помощи унифицированного языка моделирования ( UML ). Эта статья о применении диаграмм UML в рабочем процессе разработки программных систем по методологии Rational Software .
Ни для кого не секрет, что создание программного обеспечения – это сложный процесс, который, с одной стороны, имеет много общего с творчеством, а с другой, – хотя и высокодоходный, но и высокозатратный бизнес.
Жестокая конкуренция на рынке вынуждает разработчиков к поиску более эффективных методов работы. Путей создания программных систем в еще более короткие сроки, с меньшими затратами и лучшим качеством. Сложность программ постоянно увеличивается.
Еще недавно программные продукты могли быть созданы в обозримые сроки одиночками или, например, в IT -отделе автоматизируемого предприятия.
Сейчас же одиночкам, создающим программы «на коленке» остается область небольших утилит и различных модулей расширения «тяжелых» программных продуктов. Будущее за индустриальным подходом к созданию ПО.
В 1913 году Генри Форд запустил первый автомобильный конвейер, а в 90-х аналогичный конвейер стал применяться в сфере IT -технологий. Командная разработка требует совсем другого подхода и другой методологии, которая рано или поздно должна была быть создана.
Корпорация Rational Software ( http :// www . rational . com ) выпустила на рынок структурированную базу знаний под названием Rational Unified Process ( RUP )[1,2], которая представляет собой набор исчерпывающих рекомендаций для создания практически любых программных продуктов. Вобрав в себя опыт лучших разработок, RUP подробно рассказывает когда, кто и что должен делать в проекте, чтобы в результате получить программную систему с установленные сроки, с определенной функциональностью и в рамках отведенного бюджета.
Унифицированный процесс можно представить как сумму различных видов деятельности компании-разработчика, необходимых для перевода требований заказчика в программную систему. Систему, которая давала бы «значимый результат»[2] пользователям и выполняла бы именно то, что они от системы ожидают.
Поэтому процесс управляется вариантами использования ( Use Case ) системы, или иначе – прецедентами.
Для реализации требований заказчика в установленные сроки, Унифицированный процесс разделяется на фазы, которые состоят из итераций, поэтому процесс еще называют итеративным и инкрементным.
Каждая итерация проходит цикл основных работ и подводит разработчиков к конечной цели: созданию программной системы. В ходе итераций создаются промежуточные артефакты, которые требуются для успешного завершения проекта и вариант программной системы, который реализует некоторый набор функций, увеличивающийся от итерации к итерации.
Фазы и основные потоки работ процесса показаны на рис. 1, там же даны примерные трудозатраты работ по фазам.
рис. 1 Фазы и потоки работ RUP
Как выглядят регламенты и бизнес-процессы
Нужно отметить, что на рис. 1 показаны только основные работы Унифицированного процесса.
Нотации описания бизнес-процессов — IDEF0 | Naked BPM
Например, работы по управлению деятельностью здесь не показаны, чтобы не загромождать диаграмму.
Вся разработка ПО рассматривается в RUP как процесс создания артефактов. Любой результат работы проекта, будь то исходные тексты, объектные модули, документы, передаваемые пользователю, модели – это подклассы всех артефактов проекта.
Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист создает программу, руководитель — проектный план, а аналитик — модели системы. RUP позволяет определить когда, кому и какой артефакт необходимо создать, доработать или использовать.
Одним из интереснейших классов артефактов проекта являются модели, которые позволяют разработчикам определять, визуализировать, конструировать и документировать артефакты программных систем. Каждая модель является самодостаточным взглядом на разрабатываемую систему и предназначена как для очерчивания проблем, так и для предложения решения.
Самодостаточность моделей означает, что аналитик или разработчик может из конкретной модели почерпнуть всю необходимую ему информацию, не обращаясь к другим источникам.
Модели позволяют рассмотреть будущую систему, ее объекты и их взаимодействие еще до вкладывания значительных средств в разработку, позволяют увидеть ее глазами будущих пользователей снаружи и разработчиков изнутри еще до создания первой строки исходного кода.
Большинство моделей представляются UML диаграммами, подробнее об UML можно прочитать, например в [3].
Унифицированный язык моделирования ( Unified Modeling Language ) появился в конце 80-х в начале 90-х годов в основном благодаря усилиям «трех друзей» Гради Буча, Джима Рамбо и Ивара Якобсона.
В настоящее время консорциум OMG принял этот язык как стандартный язык моделирования, который предоставляет разработчикам четкую нотацию, позволяющую отображать модели общепринятыми и понятными каждому члену проекта графическими элементами.
Однако не следует забывать, что язык моделирования дает только нотацию – инструмент описания и моделирования системы, а унифицированный процесс определяет методику использования этого инструмента, как впрочем, и других инструментов поддержки методологии от компании Rational . UML можно использовать и без конкретной методологии, поскольку он не зависит от процесса и какой бы вариант процесса не был бы применен, вы можете использовать диаграммы для документирования принятых в ходе разработки решений и отображения создаваемых моделей.
Программная система создается для решения определенных проблем пользователя, а не для опробования новых технологий программистами и получения опыта руководителем проекта. По большому счету, пользователю не важно используете ли вы в процессе разработки объектно-ориентированный подход, UML , RUP или создаете систему по методу XP (экстремального программирования) [4].
Применение тех или иных методик, технологий, создание оптимальной внутренней структуры проекта остается на совести разработчиков, которые принимают решения исходя из предыдущего опыта и собственных предпочтений. Однако пользователь не простит вам игнорирование его требований.
Будь программная система хоть десять раз разработана при помощи суперсовременных методов и технологий, если пользователь не получит от нее то, что называется «значимым результатом», ваш программный проект с треском провалится.
Из этого следует, что бездумное применение UML , просто потому что это модно, не только не приведет разработку к успеху, но и может вызвать недовольство сотрудников, которым необходимо изучать большое количество дополнительной литературы и руководителей проекта, когда окажется, что трудозатраты на проекте возрастают, а отдача не повышается.
Нужно четко представлять себе, что вы хотите получить от внедрения этой технологии и следовать этой цели. Применение UML экономит ресурсы разработки, поскольку позволяет получить представление о системе быстрее, чем при создании макетов и прототипов, затратив на это несравнимо меньше ресурсов.
Диаграммы позволяет легче общаться членам проекта между собой, и, что особенно ценно, вовлекают в процесс конечных пользователей системы. Моделирование позволяет уменьшить риски проекта, поскольку программистам всегда легче делать то, что ясно и понятно, чем идти к неопределенному результату.
Создание диаграмм аналогично созданию проекта в строительстве – можно обойтись и без него, например, при строительстве сарая на дачном участке, однако, чем больше здание (в нашем случае программный продукт), тем труднее это делать и неопределеннее конечный результат.
Однажды я проводил семинар по RUP в компании-разработчике программного обеспечения, которая уже десять лет довольно успешно работает на рынке, но не использует в своем рабочем процессе моделирования вовсе, а основывается на прототипах.
В зале собралось около двадцати молодых и умудренных опытом программистов, которые внимательно прослушали все, что я им рассказал о RUP и UML . И вот один из них, посмотрев на доску, испещренную примерами диаграмм, заметил: «Это все интересно и, наверное, хорошо подходит для других проектов», – сказал он, «но мы работаем довольно давно без всего этого, раз мы до сих пор обходились без UML , он, наверное, нам это просто не нужен».
Этот вопрос заставил меня задуматься о том, что изменение бизнес-процессов, которое неизбежно должно произойти в компании-разработчике программного обеспечения при внедрении RUP и UML может проходить также тяжело, как внедрение информационной системы на промышленном предприятии. Любое внедрение – это ломка стереотипов. Поскольку квалификация сотрудников в компании-разработчике ПО довольно высока, то и отказаться от своих взглядов таким людям труднее, чем «простым смертным», а возникающие трудности и неприятие можно сравнить с переходом от процедурного к объектно-ориентированному мышлению.
1.Определение требований
Унифицированный процесс – это процесс, управляемый прецедентами, которые отражают сценарии взаимодействия пользователей. Фактически, это взгляд пользователей на программную систему снаружи.
Таким образом, одним из важнейших этапов разработки, согласно RUP , будет этап определения требований, который заключается в сборе всех возможных пожеланий к работе системы, которые только могут прийти в голову пользователям и аналитикам. Позднее эти данные должны будут систематизированы и структурированы, но на данном этапе в ходе интервью с пользователями и изучения документов, аналитики должны собрать как можно больше требований к будущей системе, что не так просто, как кажется на первый взгляд. Пользователи часто сами не представляют, что они должны получить в конечном итоге. Для облегчения этого процесса аналитики используют диаграммы прецедентов (рис. 2)
рис 2. Пример диаграммы Прецедентов
Диаграмма представляет собой отражение действующих лиц (актантов), которые взаимодействуют с системой, и реакцию программных объектов на их действия. Актантами могут быть как пользователи, так и внешние агенты, которым необходимо передать или получить информацию. Значок варианта использования отражает реакцию системы на внешнее воздействие и показывает, что должно быть сделано для актанта.
Для детализации конкретного прецедента используется диаграмма Активности ( Activity Diagram ), пример которой дан на рис 3.
рис. 3 Пример диаграммы Активности
Простота диаграммы прецедентов позволяет аналитикам легко общаться с заказчиками в процессе определения требований, выявлять ограничения, налагаемые на систему и на выполнение отдельных требований, такие, например, как время реакции системы, которые в дальнейшем попадают в раздел нефункциональных требований.
Также диаграмма прецедентов может использоваться для создания сценариев тестирования, поскольку все взаимодействие пользователей и системы уже определено.
Для того чтобы верно определить требования, разработчики должны понимать контекст (часть предметной области) в котором будет работать будущая система. Для этого создаются модель предметной области и бизнес-модель, что является различными подходами к одному и тому же вопросу. Часто создается что-то одно: модель предметной области или бизнес-модель.
Отличия этих моделей в том, что модель предметной области описывает важные понятия, с которыми будет работать система и связи их между собой. Тогда как бизнес-модель описывает бизнес-процессы (существующие или будущие), которые должна поддерживать система. Поэтому кроме определения бизнес-объектов, вовлеченных в процесс, эта модель определяет работников, их обязанности и действия, которые они должны выполнять.
Для создания модели предметной области используется обычная диаграмма классов (рис 6), однако для создания бизнес-модели ее уже явно недостаточно. В этом случае применяется диаграмма прецедентов с использованием дополнительных значков, которые отражающие сущность бизнес-процессов – это бизнес-актант, бизнес-прецедент, бизнес-сущность и бизнес-управление. Эта модель намного ближе к следующей модели, создаваемой в процессе разработки – модели анализа.
2.Анализ
После определения требований и контекста, в котором будет работать система, наступает черед анализа полученных данных. В процессе анализа создается аналитическая модель, которая подводит разработчиков к архитектуре будущей системы. Аналитическая модель – это взгляд на систему изнутри, в отличие от модели прецедентов, которая показывает, как система будет выглядеть снаружи.
Эта модель позволяет понять, как система должна быть спроектирована, какие в ней должны быть классы и как они должны взаимодействовать между собой. Основное ее назначение — определить направление реализации функциональности, выявленной на этапе сбора требований и сделать набросок архитектуры системы.
В отличие от создаваемой в дальнейшем модели проектирования, модель анализа является в большей степени концептуальной моделью и только приближает разработчиков к классам реализации. Эта модель не должна иметь возможных противоречий, которые могут встретиться в модели прецедентов.
Для отображения модели анализа при помощи UML используется диаграмма классов со стереотипами (образцами поведения) «граничный класс», «сущность», «управление», а для детализации используются диаграммы сотрудничества ( Collaboration ) (рис 4). Стереотип «граничный класс» отображает класс, который взаимодействует с внешними актантами, «сущность» – отображает классы, которые являются хранилищами данных, а «управление» – классы, управляющие запросами к сущностям.
рис 4. Пример диаграммы сотрудничества
Нумерация сообщений показывает их порядок, однако назначение диаграммы не в том, чтобы рассмотреть порядок обмена сообщениями, а в том, чтобы наглядно показать связи классов друг с другом.
Если акцентировать внимание на порядке взаимодействия, то другим его представлением будет диаграмма последовательности ( Sequence ), показанная на рис 5. Эта диаграмма позволяет взглянуть на обмен сообщениями во времени, наглядно отобразить последовательность процесса. При использовании такого инструмента для создания моделей как Rational Rose , эти два вида диаграмм могут быть созданы друг из друга автоматически (подробнее о Rational Rose можно прочитать, например, в [5]).
Рис. 5 Пример диаграммы последовательности действий
Решение о том, какую из двух диаграмм нужно создавать первой, зависит от предпочтений конкретного разработчика. Поскольку эти диаграммы являются отображением одного и того же процесса, то и та и другая позволяют отразить взаимодействие между объектами.
3.Проектирование
Следующим этапом в процессе создания системы будет проектирование, в ходе которого на основании моделей, созданных ранее, создается модель проектирования. Эта модель отражает физическую реализации системы и описывает создаваемый продукт на уровне классов и компонентов. В отличие от модели анализа, модель проектирования имеет явно выраженную зависимость от условий реализации, применяемых языков программирования и компонентов. Для максимально точного понимания архитектуры системы, эта модель должна быть максимально формализована, и поддерживаться в актуальном состоянии на протяжении всего жизненного цикла разработки системы.
Для создания модели проектирования используются целый набор UML диаграмм: диаграммы классов (рис. 5), диаграммы кооперации, диаграммы взаимодействия, диаграммы активности.
рис 6. Пример диаграммы классов
Дополнительно в этом рабочем процессе может создаваться модель развертывания, которая реализуется на основе диаграммы развертывания ( Deployment Diagram ). Это самый простой тип диаграмм, предназначенный для моделирования распределения устройств в сети. Для отображения используется всего два варианта значков процессор и устройство вместе со связями между ними.
4.Реализация
Основная задача процесса реализации – создание системы в виде компонентов – исходных текстов программ, сценариев, двоичных файлов, исполняемых модулей и т.д. На этом этапе создается модель реализации, которая описывает то, как реализуются элементы модели проектирования, какие классы будут включены в конкретные компоненты. Данная модель описывает способ организации этих компонентов в соответствии с механизмами структурирования и разбиения на модули, принятыми в выбранной среде программирования и представляется диаграммой компонентов (рис. 7).
рис. 7 Пример диаграммы компонентов
5.Тестирование
В процессе тестирования проверяются результаты реализации. Для данного процесса создается модель тестирования, которая состоит из тестовых примеров, процедур тестирования, тестовых компонентов, однако не имеет отображения на UML диаграммы, поэтому не будем на ней останавливаться.
6.Заключение
Здесь были рассмотрены только основные процессы методологии Rational . RUP довольно обширен, и содержит рекомендации по ведению различных программных проектов, от создания программ группой разработчиков в несколько человек, до распределенных программных проектов, объединяющих тысячи человек на разных континентах. Однако, несмотря их колоссальную разницу, методы применения моделей, создаваемых при помощи UML будут одни и те же. Диаграммы UML , создаваемые на различных этапах разработки, неотделимы от остальных артефактов программного проекта и часто являются связующим звеном между отдельными процессами RUP .
Решение о применении конкретных диаграмм зависит от поставленного в компании процесса разработки, который, хотя и называется унифицированным, однако не есть нечто застывшее. Компания Rational не только предлагает его улучшать и дорабатывать, но и предоставляет специальные средства внесения изменений в базу данных RUP .
Но в любом случае, применение UML вместе с унифицированным процессом позволит получить предсказуемый результат, уложиться в отведенный бюджет, повысить отдачу от участников проекта и качество создаваемого программного продукта.
[1] Крачтен . Ф . Введение в Rational Unified Process. Изд . 2- е .- М.: Издательский дом «Вильямс», 2002. — 240 с.: ил.
[2] Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения — Спб.: Питер, 2002. — 496 с.: ил.
[3] Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.:Мир, 1999. – 191 с., ил.
[4] Бек. Е. Экстремальное программирование. – Спб.: Питер, 2002. – 224 с.: ил.
[5] Трофимов С. CASE-технологии: Практическая работа в Rational Rose.
Изд. 2-е.- М.: Бином-Пресс, 2002 г. — 288 с.
Источник: www.caseclub.ru
Что такое унификация — ее виды и сферы применения
Сегодня займемся толкованием термина, который применяется во многих отраслях человеческой деятельности, но в каждой из них имеет собственные нюансы.
Поговорим об унификации – что это такое, для чего нужна.
Подробней остановимся на унификации в технической сфере и в документообороте (что это?).
Унификация – это…
На нашей планете, где живут более 7,5 миллиардов человек, не встретишь двух абсолютно одинаковых людей. Мы все разные, и это прекрасно. Так было задумано природой или Богом (это уж кому как нравится). Единственное, чем мы (люди) схожи, так это строением тела и его внутренним наполнением.
В этом нас природа все же стандартизировала – дала по четыре конечности и по одной голове. То есть мы все-таки немного унифицированы – приведены к единообразной форме.
Унификация – сложносоставное слово, произошло от двух латинских слов «unus» и «facio». Что в переводе на русский буквально означает «один» и «делаю, объединяю».
Следовательно, унификация – это приведение некоторых объектов к единой форме.
В любой сфере человеческой деятельности оперирование бесконечным многообразием объектов ведет к значительному снижению эффективности этой деятельности.
Поэтому унификация – это путь к стандартизации процесса и, следовательно, к увеличению производительности.
Простой пример: на швейной фабрике в день выпускается сотня платьев ограниченного модельного ряда. А в ателье индивидуального пошива за этот же срок – только одно изделие.
И это легко объяснимо: на фабрике используются унифицированные лекала, каждую отдельную операцию выполняет специальный работник (или автомат, но это не принципиально). А в ателье на клиента создается индивидуальная выкройка, подбирается оригинальный фасон, и весь процесс пошива, как правило, выполняется одним мастером.
Унификация, как метод стандартизации, применяется во многих сферах.
Кратко – о некоторых из них:
- унификация в юридическом праве – это разработка единых норм для регулирования какого-либо вида правоотношений. Необходима для упрощения применения правовых норм в жизненных ситуациях. Основным методом унификации в праве является кодификация, т.е. нумерация, разделение на параграфы, части, статьи и т.д.;
- унификация в компьютерной сфере направлена на улучшение взаимозаменяемости и совместимости компьютерного «железа», а также программного обеспечения. Достигается определенными договоренностями ведущих производителей о конструктивном единообразии выпускаемой продукции, о терминах, названиях, классификации и т.д.;
- унификация в строительстве – это создание типовых модульных составляющих, которые могут применяться в строительстве зданий определенного назначения.
Далее рассмотрим более подробно унификацию в технике и в делопроизводстве.
Унификация в технике
Главная цель унификации технических объектов – уменьшение их разнородности с целью увеличения производительности и максимизации их совместимости.
Унификация в этой сфере достигается с помощью 2 основных способов:
- типизация, т.е. созданием типовых проектов и типовых изделий;
- систематизация, т.е. классификацией (что это такое?) различных технических объектов в зависимости от определенных признаков в некоторые системы, которые облегчают пользование этими объектами.
Если говорить проще, то унификация позволяет применять одни и те же детали, комплектующие и т.д. для различных технических объектов.
Если рассматривать унификацию в аспекте (что это?) кого-либо технологического процесса, то использование, например, одного вида шурупов при сборе корпусной мебели позволяет применять только один вид инструмента на выполнение этой операции.
Унификация способствует выпуску серийных изделий, что значительно снижает себестоимость их производства.
Уровень унификации при выпуске конкретного изделия определяется как отношение унифицированных элементов в его составе к общему количеству элементов. Формула:
- УУ – уровень унификации изготовления изделия;
- ЭУ – кол-во унифицированных элементов;
- ЭО – общее кол-во элементов в изделии.
Методы унификации в технической сфере:
- Модифицирование – изменение существующего объекта методом корректировки некоторых (но не значимых) элементов. Например, разработан рецепт пирожного. Изменили его оформление → получили модификацию изделия;
- Метод базового агрегата – есть базовая часть (агрегат) и есть несколько дополнительных частей, которые можно заменять и варьировать в различных объемах, создавая дополнительные опции. Например, есть холодильный агрегат – это базовая часть холодильника. Делаем 1 или 2 камеры, получаем различные виды холодильников, добавляем опцию разморозки – получаем еще одну модель холодильника и т.д.;
- Компаундирование – параллельное присоединение нескольких однотипных объектов для увеличения производительности (мощности). Пример такого способа унификации вы видели в железнодорожном транспорте – электровозы, состоящие из нескольких электровозов;
- Принцип модульности – выпуск одного изделия и дополнительного оборудования для него. Так, трактор, легким движением руки превращается в сеялку или распрыскиватель химикатов посредством присоединения к нему соответствующего навесного оборудования.
Унификация в делопроизводстве
Вообразим на минутку, что все документы составляются в произвольной форме. Представили хаос, который будет твориться в мире? Сколько времени будет затрачиваться на обработку одного документа, а как будет выглядеть бухучет?
Чтобы не допустить такого безобразия, весь документооборот построен на принципе унифицированности. Практически каждый официальный документ является унифицированным.
Унификация документов основана на применении определенного формата бумажного носителя, конкретизации перечня реквизитов (что это?) документа, стандарт записи этих реквизитов.
Суть унификации документов – в минимизации их многообразия и в регламентировании оформления, ведения и хранения.
Для унификации делопроизводства в РФ разработана единая государственная система делопроизводства (ЕГСД). А для оформления документов – унифицированная система документации (УСД).
Надеюсь, что эта статья снабдила вас некоторой порцией новой информации. Читайте наш блог – и будьте на шаг впереди всех!
Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru
Эта статья относится к рубрикам:
Думаю, что унификация и стандартизация успешно применяются и в социальной сфере. Не зря же существуют такие термины, как стандарты красоты и жизни в целом. СМИ легко навязывают людям определенный образец поведения и внешности.
В технике всё что только можно подлежит унифицикации, даже шаг и геометрия резьбы резьбовых соединений, размеры болтов, гаек, подшипников, есть таблицы по которым инженеры выбирают стандартный размер отталкиваясь от расчётного.
Не зря и девушки-модели все со стандартной фигурой, ведь для показов шьют одежду одного размера и любая модель без проблем должна надеть любое платье, так что, унификация делает жизнь намного проще.
Привет всем. И спасибо за статью очень благодарен, всегда задумывался над этим термином
В технической сфере и строительстве унификация важна, но не хотелось бы чтобы и в социальную сферу она проникала — даже в образовании уже все регламентировано!
Вся эта унификация приводит к однотипности, понятно, когда это касается крепёжных деталей, но вот когда унифицируют целые проекты, например жилых зданий, вот тогда мы и получаем безликие дома — коробки.
Ваш комментарий или отзыв
Источник: ktonanovenkogo.ru
Что такое UС: как меняется российский рынок унифицированных коммуникаций
Ещё в начале 2022 года многие российские компании использовали иностранные UC-решения, которые позволяли эффективно выстраивать работу удалённых сотрудников. После ухода зарубежных проектов из России увеличился спрос на отечественные решения. О том, что могут предложить российские IT-компании в этой сфере и как будут развиваться их продукты с учётом санкций, в своей авторской колонке для портала Biz360.ru рассказал Артём Чепрак, директор компании «Информтехника и связь».
Артём Чепрак – генеральный директор компании «Информтехника и связь» . Окончил МАТИ-РГТУ по специальности «Проектирование и технология электронных средств». В 2011 году получил степень MBA по управлению производством. Имеет 19-летни й опыт в производстве отечественной техники и электроники.
Офисные перемены
Пандемия коронавируса серьёзно повлияла на формат работы практически каждого бизнеса в России. Введённый локдаун заставил компании спешно переходить на удалённый формат работы. Тем, кто до этого не задумывался об использовании UC – унифицированных коммуникаций, которые позволяют сотрудникам общаться в одном виртуальном пространстве – пришлось спешно их осваивать. Полученный экономический эффект от дистанционной работы придал импульс развитию UC в нашей стране.
Бизнес понял, что ему выгоден удалённый формат работы сотрудников – минимизируются издержки на аренду офиса, повышается лояльность персонала к компании, а за счёт UС появляются инструменты по контролю и управлению сотрудниками, работающими на дому.
После событий в Украине российские компании стали активно искать альтернативу зарубежным решениям в сфере унифицированных коммуникаций. До этого большинство предприятий использовали зарубежные UC-технологии, наиболее востребованными из них были Cisco и MS Teams.
При этом существовали и российские платформы, но их доля составляла всего 5% рынка. Сейчас растёт спрос на отечественные аналоги: мы это видим и по рынку в целом, и на примере собственного решения. Интересу к отечественным решениям способствует их цена, а также уход или риск ухода иностранных компаний из России.
Экономический эффект от отечественных решений
Внедрение в бизнес-процессы компаний новых отечественных технологий для унифицированных коммуникаций обеспечит развитие сервисов, позволяющих оперативно обмениваться данными между сотрудниками и отделами. К таким площадкам можно отнести электронную почту, различные мессенджеры, аудио- и видеоконференцсвязь, электронный документооборот .
Одним из ключевых преимуществ современного UC-решения является гибкость. Оно содержит не только множество опций, позволяющих адаптировать платформу под конкретные бизнес-процессы компании, но и возможность интеграции с различными системами, уже развернутыми на предприятии.
UC ускоряет бизнес-процессы и обеспечивает быструю и надёжную связь между сотрудниками. Это позволяет офисному, мобильному и дистанционно работающему персоналу организовать эффективное взаимодействие и обмен информацией, несмотря на расстояния и различные часовые пояса.
Способы управления статусом присутствия, мобильные возможности, а также средства организации аудио-, веб- и видеоконференций повышают производительность труда сотрудников. Вместе с этим одновременно сокращаются расходы на связь, аренду помещений, и сводится к минимуму потребность в командировках.
Ещё одно преимущество российских UC – они доступнее по цене, чем зарубежные аналоги. Также их разработчики могут реализовать конкретные пожелания заказчика, проявив большую гибкость.
Перспективы российского IT-рынка
UC-платформы востребованы как среди представителей как крупного, так и среднего и малого бизнеса. Кроме того, они стимулируют развитие рынка облачных технологий, использование которых – ещё один тренд российского IT-рынка.
По прогнозам, сегмент «облаков» в России к концу 2022 вырастет на 30-35% . Драйверам роста станет то, что отечественные облачные решения зачастую стоят дешевле импортных, а также гораздо выгоднее, чем коробочные.
Они не требуют места на серверах, дополнительного персонала, который обеспечивал бы бесперебойную работу инфраструктуры. Всю поддержку производит подрядчик, он обеспечивает бесперебойную работу решений, что позволяет существенно экономить бюджет.
Но у облачных решений есть и недостатки, связанные с информационной безопасностью. Если заказчик хочет быть уверенным, что все данные, которые проходят в UC, защищены, то лучший выход – установить систему локально, у себя на сервере.
Наша страна может достигнуть технологического суверенитета в течение 10-20 лет. Если говорить о конкретных разработках UC-платформ, то, помимо нас многие российские IT-компании предлагают подобные продукты для решения бизнес-задач.
Ситуация с программным обеспечением более оптимистична. Российские разработчики не только «копируют» зарубежные идеи, но и создают свои, трендовые проекты, востребованные во всём мире. В том числе и UC. На примере нашей компании можно сказать, что уже существует система унифицированных коммуникаций ёмкостью до 1 млн. абонентов, включающая в себя комбинированную IP АТС, корпоративный мессенджер и ВКС.
Если говорить про «железо» для IT-индустрии, то проблематика существует, так как российская микроэлектроника остановилась в развитии ещё во времена СССР. Необходимо открывать производства, разрабатывать собственные новые технологии, а для этого необходимо растить кадры. Данная перестройка затянется на несколько лет, но тут бизнес либо принимает вызов, либо капитулирует.
Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал , страницу в «ВКонтакте» и канал на «Яндекс.Дзен» .
biz360
Источник: biz360.ru