Часть 3. Информационные технологии в экономике и управлении.

Часть 3. Информационные технологии в экономике и управлении.

Раздел 1. Проектирование экономических информационных систем. Автоматизированные системы бухгалтерского учета.

Обеспечивающие подсистемы ИС

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

Состав обеспечивающих подсистем не зависит от выбранной предметной области и имеет

● функциональную структуру;

● информационное обеспечение;

● математическое (алгоритмическое и программное) обеспечение;

● техническое обеспечение;

● организационное обеспечение - это совокупность средств и ме­тодов организации производства и управления ими в условиях внедрения ИС;

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

а на стадии разработки ИС дополнительные обеспечения:

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

· лингвистическое;

· технологическое;

· методологическое;

· интерфейсы с внешними ИС.

 

Функциональная структура

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

Информационные функции - это централизованный контроль (1 - измерение значений параметров, 2 - измерение их отклонений от заданных значений) и вычислительные и логические операции (3 - тестирование работоспособности ИС и 4 - подготовка и обмен информацией с другими системами). Управляющие функции должны осуществлять: 5 - поиск и расчет рациональных режимов управления, 6 - реализацию заданных режимов управления.

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

 

Основные компоненты технологии проектирования ИС

Требования, предъявляемые к технологии проектирования ИС

n Технология должна поддерживать полный жизненный цикл системы;

n технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

n технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем;

n технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами;

n технология должна обеспечивать минимальное время получения работоспособной ИС;

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

n технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС;

n технология должна быть поддержана комплексом согласованных CASE-средств.

Преимущества

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

· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

· положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

· приемлемый уровень отдачи от инвестиций в CASE-средства

 

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

 

1. принцип всесторонней компьютерной поддержки проектирования.

 

2. принцип модельного подхода. CASE – система может поддерживать методологию функционально –ориентированного или объектно-ориентированного подхода

 

3. принцип иерархического представления модели предметной области. Данный принцип выражается в возможности последовательной детализации (декомпозиции) описания системы в соответствии с нисходящим подходом проектирования.

 

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

 

5. принцип декомпозиции процесса ПИС с применением CASE –технологий на стадии и этапы.

 

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

Классификация CASE средств

Современные CASE-системы классифицируются по следующим признакам:

 

1) По поддерживаемым методологиям проектирования: функ­ционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);

 

2) По поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

3) По степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);

 

4) По типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;

 

5) По режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

 

6) По типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).

 

Рассмотрим классификацию Case-средств по типам и категориям.

 

Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ и включает следующие типы:

 

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

 

К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun Technologies), Oracle Designer (Oracle), Rational Rose (Rational Software), Paradigm Plus (PLATINUM technology), Power Designer (Sybase), System Architect (Popkin Software).

 

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

 

2. Средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL – Structured Query Language – структурированном языке запросов) для наиболее распространенных СУБД. Средства проектирования баз данных имеются в составе таких CASE-средств, как Silverrun, Oracle Designer, Paradigm Plus, Power Designer. Наиболее известным средством, ориентированным только на проектирование БД, является ERwin (PLATINUM technology);

3. Средства управления требованиями, обеспечивающие комплексную поддержку разнородных требований к создаваемой системе.

 

Примерами таких средств являются RequisitePro (Rational Software) и DOORS – Dynamic Object-Oriented Requirements System – динамическая объектно-ориентированная система управления требованиями (Quality Systems and Software Inc.);

 

4. Средства управления конфигурацией ПО – PVCS (Merant), ClearCase (Rational Software) и др.;

 

Средства документирования.

 

Наиболее известным из них является SoDA – Software Document Automation – автоматизированное документирование ПО (Rational Software);

 

Средства тестирования.

 

Наиболее развитым на сегодняшний день средством является Rational Suite TestStudio (Rational Software) набор продуктов, предназначенных для автоматического тестирования приложений;

 

7. Средства управления проектом – Open Plan Professional (Welcom Software), Microsoft Project 98 и др.;

 

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

 

Средства анализа схем БД и формирования ERD входят в состав таких CASE-средств, как Silverrun, Oracle Designer, Power Designer, ERwin. Анализаторы программных кодов имеются в составе Rational Rose и Paradigm Plus.

 

Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство процессов ЖЦ ПО (toolkit), и полностью интегрированные средства, поддерживающие весь ЖЦ ПО и связанные общим репозиторием.

 

Помимо этого, CASE-средства можно также классифицировать по применяемым структурным или объектно-ориентированным методам анализа и проектирования ПО.

 

Архитектура CASE - средств

 

 

 

Диаграммы потоков данных (DFD)

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

• первый уровнь (IDEF0) - перечень бизнес-процессов;

• второй уровень (IDEF3) - функции, которые выполняются в пределах бизнес-процессов;

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

Элементы графической нотации DFD

 

Варианты организации информационной базы ИС

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

Существует два способа организации информационной базы (ИБ):

· совокупность локальных файлов, которые поддерживаются функциональными пакетами прикладных программ;

· интегрированные базы данных, основанные на использовании СУБД.

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

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

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

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

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

Примеры базовых показателей

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

2) особенностей процесса, используемого для получения ко­нечного продукта, в частности его способность избегать непроизводительных видов деятельности (переделок, бю­рократических проволочек, затрат на взаимодействие);

3) возможностей персонала, участвующего в разработке ПО, в особенности его профессионального опыта и знания пред­метной области проекта;

4) среды, которая состоит из инструментов и методов, исполь­зуемых для эффективного выполнения разработки ПО и ав­томатизации процесса;

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

Соотношение между этими параметрами, с одной стороны, и рассчитываемой трудоемкостью с другой, может быть записано следующим образом:

Трудоемкость = (Персонал) • (Среда) • (Качество) • (Размер проекта ^{процесс})

Размер проекта может быть единственным показателем.

Наиболее влиятельный фактор оценки трудоемкости в этих моделях — размер программного продукта. Процедура оценки трудоемкости разработки ПО состоит из следующих действий:

1. оценка размера разрабатываемого продукта;

2. оценка трудоемкости в человеко-месяцах или человеко-часах;

3. оценка продолжительности проекта в календарных месяцах;

4. оценка стоимости проекта.

Оценка размера продукта базируется на знании требований к системе. Для такой оценки существуют два основных способа.

· По аналогии. Если в прошлом приходилось иметь дело с по­добным проектом, и его оценки известны, то можно, оттал­киваясь от них, приблизительно оценить свой проект.

· Путем подсчета размера по определенным алгоритмам на
основе исходных данных — требований к системе.

Проблемы оценки размера ПО.

· Проблема может быть недостаточно хорошо понята разра­ботчиками и (или) заказчиками из-за того, что некоторые факты были упущены или искажены.

· Недостаток или полное отсутствие исторических данных не позволяет создать базу для оценок в будущем.

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

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

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

· Возможности оценивания существенно зависят от субъек­тов, вовлеченных в процесс оценивания.

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

Основными единицами измерения размера ПО являются:

· количество строк кода (LOC - Lines of Code);

· функциональные точки (FP — Function Points).

Преимущества использования LOC в качестве единиц изме­рения:

· широкое распространение и легкая адаптируемость;

· возможность сопоставления методов измерения размеров и производительности в различных группах разработчиков;

· непосредственная связь с конечным продуктом;

· легкая оценка до завершения проекта;

· оценка размеров ПО на основе точки зрения разработчика — физическая оценка созданного продукта (количество напи­санных строк кода).

Недостатки применения LOC:

· LOC затруднительны в применении при оценке размера ПО на ранних стадиях разработки;

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

· применение методов оценки с помощью подсчета количест­ва строк кода не регламентируется промышленными стан­дартами (например, ISO);

· разработка ПО может быть связана с большими затратами, которые прямо не зависят от размеров программного кода — «фиксированными затратами», такими, как спецификации требований и пользовательские документы, не включенны­ми в прямые затраты на кодирование;

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

· при подсчете количества LOC следует различать автомати­чески и вручную созданный код - эта задача является бо­лее сложной, чем простой подсчет, который может быть выполнен на основе листинга, сгенерированного компи­лятором, либо с помощью утилиты, выполняющей подсчет строк кода;

· показатели LOC не могут применяться при осуществлении нормализации в случае, если применяемые платформы раз­работки или языки являются различными;

· единственный способ учета с помощью LOC по отношению к разрабатываемому ПО заключается в использовании ме­тода аналогии на основе сравнения функциональных свойств у подобных программных продуктов, либо в ис­пользовании мнений экспертов (однако эти методы не от­носятся к числу точных);

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

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

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

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

· в организации аккуратно документируются реальные ре­зультаты предыдущих проектов;

· по крайней мере, один из предыдущих проектов (а лучше несколько) имеет аналогичный характер и размер;

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

4. Закон Паркинсона. Согласно этому закону усилия, затра­ченные на работу, распределяются равномерно по вьщеленному на проект времени. Здесь критерием для оценки затрат по проек­ту являются человеческие ресурсы, а не целевая оценка самого программного продукта. Если проект, над которым работают пять человек, должен быть закончен в течение 12 месяцев, то зат­раты на его выполнение исчисляются в 60 человеко-месяцев.

5. Оценка с целью выиграть контракт (оценка, используемая для Тендера ). Затраты на проект опре­деляются наличием тех средств, которые имеются у заказчика. Поэтому трудоемкость проекта зависит от бюджета заказчика, а не от функциональных характеристик создаваемого продукта. Требования приходится изменить так, чтобы не выходить за рам­ки принятого бюджета.

 

МЕТОД ДЕЛЬФИ

Метод Дельфи был разработан в корпорации «Рэнд» в конце 1940-х гг. и использовался первоначально для прогнозирования будущих событий. Позднее метод использовался для принятия решений по спорным вопросам. Изначально в методе Дельфи коллективное обсуждение не ис­пользовалось; обсуждение между этапами метода было впервые применено в обобщенном методе Дельфи. Метод достаточно эф­фективен в том случае, если необходимо сделать заключение по некоторой проблеме, а доступная информация состоит больше из «мнений экспертов», чем из строго определенных эмпирических данных.

МЕТОД ДЕКОМПОЗИЦИИ РАБОТ

Долгое время являясь фактическим стандартом в практике разработки как программного, так и аппаратного обеспечения, метод декомпозиции работ (МДР) представляет собой способ ие­рархической организации элементов проекта, упрощающий за­дачу составления бюджета проекта и контроля за расходованием средств. Он позволяет определить, на что именно расходуются средства. Если с каждой категорией расходов, связанной с тем или иным элементом иерархии проекта, сопоставить некоторую вероятность, можно определить ожидаемую сумму расходов на разработку, начиная с некоторых структурных элементов проекта и заканчивая совокупными затратами на выполнение всего про­екта. Методы, основанные на экспертных оценках, пригодны для проектов, связанных с разработкой принципиально нового ПО, и для совокупной оценки проектов, но содержат ряд «узких мест», упомянутых выше. Кроме того, методы, основанные на эксперт­ных оценках, плохо масштабируемы, что затрудняет масштабный анализ чувствительности. Подходы, в основу которых положен МДР, хорошо пригодны для планирования и управления.

Классификация АСБУ

Размер бухгалтерии

ü Малая (1-3 чел.)

Основные критерии выбора программного обеспечения бухгалтерского учета:

Ø унифицированная модель представления данных;

Ø единая программная среда;

Ø встроенные проблемно-ориентированные инструментальные средства;

Ø функционирование в одноранговой сети или в сети ПК с выделенным сервером;

Ø наличие сертифицированных для внедрения системы дилеров фирмы производителя ПО в собственном регионе;

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

Размер бухгалтерии

ü Средняя (4-10 чел.)

Основные критерии выбора программного обеспечения бухгалтерского учета:

Ø построение системы в виде полнофункционального набора специализированных по участкам учета программных модулей;

Ø возможность развития функций системы за счет профессиональных средств разработки;

Ø функционирование в сети ПК с выделенным сервером в архитектуре клиент-сервер;

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

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

Размер бухгалтерии

ü Крупная (больше 10 чел.)

Основные критерии выбора программного обеспечения бухгалтерского учета:

Ø построение системы в виде полнофункционального набора узко-специализированных по участкам учета программных модулей;

Ø возможность развития функций системы за счет профессиональ-ных средств разработки;

Ø возможность функционирования в неоднородных сетях, значительная независимость в выборе пользователем аппаратных средств, операционных систем и СУБД;

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

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

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

Размер бухгалтерии

ü Корпоративная

Основные критерии выбора программного обеспечения бухгалтерского учета:

Ø соответствие перечисленным требованиям по отношению к отдельным предприятиям и самостоятельным подразделениям корпорации;

Ø развитые средства репликации данных удаленных подразделений;

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

Назначение ЭП

Ø Контроль целостности передаваемого документа;

Ø Защиту от изменений (подделки) документа;

Ø Невозможность отказа от авторства;

Ø Доказательное подтверждение авторства документа.

 

Интернет-банкинг – это электронная банковская деятельность, осуществляемая в информационной среде глобальной компьютерной сети Интернет.

 

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

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

 

Интернет-банкинг включает обслуживание клиентов через Интернет путём предоставления им широкого спектра услуг:

ПРЕИМУЩЕСТВА ИНТЕРНЕТ-БАНКИНГА

- Повышение доступности банка всем потенциальным клиентам.

- Отсутствие географической привязки клиента к банку.

- Существенная экономия времени.

- Обеспечение возможности 24 часа в сутки контролировать счета клиентов.

- Повышение степени контроля со стороны клиента за своими операциями.

- Отсутствие необходимости устанавливать на стороне клиента специализированное программное обеспечение.

- Доступность новой услуги всем Интернет-клиентам банка, поскольку изменения происходят на сервере банка.

 

Электронная подпись

СПОСОБЫ ПЕРЕДАЧИ ЭЛЕКТРОННОЙ ОТЧЕТНОСТИ:

Облачная бухгалтерия

БЕЗОПАСНО:

- при аренде облачного сервиса, данные надежно защищены от возможных противоправных действий силовых структур;

- данные расположены на шифрованных массивах;

- передаваемая от пользователя (абонента) информация шифруется криптостойким алгоритмом с длиной ключа 128 бит.

НАДЕЖНО:

- гарантированная бесперебойная работа сервиса;

- высокое быстродействие;

- существенное снижение рисков по отказу в работе системы;

- резервное копирование включено в стоимость решения.

ТЕХНОЛОГИЧНО:

- сервис аренды основан на программном обеспечении лидеров рынка терминальных решений;

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

- приложение работает на беспроводных каналах передачи данных;

- возможность доступа через любой браузер, например Internet Explorer, Google Chrome.

УДОБНО:

- возможность географически распределенного доступа к облаку;

- оперативные обновления;

- линии консультаций.

 

Часть 3. Информационные технологии в экономике и управлении.

123456789Следующая ⇒

Поделиться: