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

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

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

Наиболее развитым на сегодняшний день средством является 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 - средств

Функциональное моделирование

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

1. Построение модели бизнес-процессов;

2. Проектирование организационной структуры;

3. Фиксация модели и организационной структуры в регламентной документации.

Разработка функциональных моделей с помощью семейства стандартов IDEF

 IDEF0 - методология функционального моделирования используется для осуществления рабочих процессов (Work Flow), разработанная на основании SADT. Данная методология отображает функции и структуру системы, а также материальные объекты и потоки информации, которые связывают эти функции.

 IDEF1(IDEF1X) – методология применяется для построения информационной модели, отображающая структуру и сущность информационных потоков, а также необходима для поддержки функций системы;

 IDEF2- методология, позволяющая построить динамическую модель меняющиеся во времени поведения функций, информации и ресурсов системы.

 IDEF3- методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

Концепция моделирования IDEFO

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

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

3. Передача информации. В IDEF существует ряд средств, разработанных для улучшения передачи информации:

• диаграммы, основанные на очень простой графике блоков и дуг;

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

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

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

• ограничение каждой диаграммы шестью подфункциями для облегчения чтения.

4. Строгость и точность. Выполнение правил IDEF0 требует достаточной строгости и точности, чтобы удовлетворить принципам архитектуры ICAM, не накладывая в то же время чрезмерных ограничений на аналитика. Правила IDEF включают:

• Ограничение количества деталей на каждом уровне (правило 3-6 блоков).

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

• Связность интерфейса диаграмм (номера узлов, номера блоков, С - номера).

• Связность структуры данных (ICOM-коды и использование туннельных дуг).

• Уникальность меток и наименований (отсутствие повторяющихся имен).

• Синтаксические правила для графики (блоков и дуг).

• Ограничения на ветвление дуг данных (метки для ограничений потоков данных на ветвях).

• Разделение входов и управлений (правило определения роли данных).

• Требования к меткам дуг данных (правила минимальных меток).

• Минимальное управление для функций (для каждой функции нужна, по крайней мере, одна управляющая дуга).

• Цель и точка зрения (у каждой модели есть цель и точка зрения).

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

6. "Организация" из "функций". Отделение организации от функции включено в цель модели и осуществляется отбором имен функций и связей в процессе разработки модели. Это положение входит в курс по IDEF0, а постоянное рецензирование в ходе создания модели помогает избежать точки зрения, навязанной организацией.

Последовательность создания функциональных моделей IDEF0

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

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

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

4. Описание элементарной бизнес-операции осуществляется посредством задания алгоритма ее выполнения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методология информационного моделирования данных IDEF1x

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

Данная нотация применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, разработки на её основе базы данных. В настоящий момент существует новая версия IDEF1 - IDEF1X. В частности данная нотация предназначена для разработки реляционных баз данных. Основные объекты нотации:

• Сущности (Entities). Отражают совокупность экземпляров со схожими свойствами, но отличаемых по одному или нескольким признакам

• Связи (Relations). Отражают соотношение сущностей между собой

Графическая нотация

Методы оценки трудоемкости создания ПО ИС и их классификация

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

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

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

Методика оценки трудоемкости разработки ПО ИС на основе функциональных точек.

Согласно данной методике трудоемкость вычисляется на ос­нове функциональности разрабатываемой системы, которая определяется на основе выявления функциональных  типов — логических групп взаимосвязанных данных, используемых и поддерживаемых приложением, а также элементарных про­цессов, связанных с вводом и выводом информации.  Порядок расчета трудоемкости разработки ПО:  • определение количества и сложности функциональных ти­пов приложения;  • определение количества связанных с каждым функциональ­ным типом элементарных данных (DET), элементарных записей (RET) и файлов типа ссылок (FTR);  • определение сложности (в зависимости от количества DET,  RET и FTR);  • подсчет количества функциональных точек приложения;  • подсчет количества функциональных точек с учетом общих  характеристик системы;  • оценка трудоемкости разработки (с использованием различ­ных статистических данных).  ОПРЕДЕЛЕНИЕ ФУНКЦИОНАЛЬНЫХ ТИПОВ  В состав функциональных типов включаются следующие элементы приложений разрабатываемой системы.  1.Внутренний логический файл (ILF) — иден­тифицируемая совокупность логически взаимосвязанных записей данных, поддерживаемая внутри приложения посредством  элементарного процесса.  2. Внешний интерфейсный файл (Elf) — идентифицируемая совокупность логически взаимосвязанных за­писей данных, передаваемых другому приложению или получае­мых от него и поддерживаемых вне данного приложения.  3. Входной элемент приложения (EI) — элемен­тарный процесс, связанный с обработкой входной информации приложения — входного документа или экранной формы. Обрабатываемые данные могут соответствовать одному или более ILF.  4. Выходной элемент приложения (ЕО) — эле­ментарный процесс, связанный с обработкой выходной инфор­ приложения — выходного отчета, документа, экранной  формы.

5. Внешний запрос (EQ) ~ элементарный про­цесс, состоящий из комбинации «запрос/ответ», не связанный с вычислением производных данных или обновлением ILF (базы данных).  Виды функциональных типов Эффективность работы конечных пользователей определяется наличи­ем следующих функциональных возможностей. 

0 –нет функцион-ых зависимости

1-от 1 б до 3

2-от 4б до 5

От 4 и более+интерфейс проектировался отдельно

5- +ИС не имеет спец ср-ва, оценивабщие работу польз. Инф си-ма имеет спец ср-ва, оценивающие работу пользоват.

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

  Онлайновое обновление  0 Отсутствует  1 Онлайновое обновление от одного до трех управляющих файлов  Объем обновлений незначителен, восстановление несложно  2 Онлайновое обновление четырех или более управляющих файлов  Объем обновлений незначителен, восстановление несложно  3 Онлайновое обновление основных внутренних логических файлов  4 То же, плюс необходимость специальной защиты от потери данных  5 То же, кроме того, большой объем данных требует учета затрат на  процесс восстановления. Требуются автоматизированные процеду­  ры восстановления с минимальным вмешательством оператора  Сложная обработка 0 Ни одной из перечисленных функциональных возможностей^  1 Любая одна из возможностей  2 Любые две из возможностей  ^ Любые три из возможностей  ^ Любые четыре из возможностей  5 Все пять возможностей  • повышенная реакция на внешние воздействия и (или) специаль­  ная защита от внешних воздействий;  • экстенсивная логическая обработка;  • экстенсивная математическая обработка;  • обработка большого количества исключительных ситуаций;  • поддержка разнородных типов входных/выходных данных.  Повторное использование  0 Отсутствует  1 Повторное использование кода внутри одного приложения  2 Не более 10% приложений будут использоваться более чем одним  пользователем  3 Более 10% приложений будут использоваться более чем одним поль­  зователем  4 Приложение оформляется как продукт и (или) документируется для  облегчения повторного использования. Настройка приложения вы­  полняется пользователем на уровне исходного кода.  5 То же, с возможностью параметрической настройки приложений  Простота установки  0 К установке не предъявляется никаких специальных требований.  1 Для установки требуется специальная процедура  2 Заданы пользовательские требования к конвертированию (переносу  существующих данных и приложений в новую систему) и установке,  должны быть обеспечены и проверены соответствующие руковод­  ства. Конвертированию не придается важное значение  3 То же, однако конвертированию придается важное значение.  4 То же, что и в случае 2, плюс наличие автоматизированных средств  конвертирования и установки  5 То же, что и в случае 3, плюс наличие автоматизированных средств  конвертирования и установки  Простота эксплуатации  О- К эксплуатации не предъявляется никаких специальных требова­  ний, за исключением обычных процедур резервного копирования  1—4 Приложение обладает одной, несколькими или всеми из перечис­  ленных далее возможностей. Каждая возможность, за исключением  второй, обладает единичным весом: 1) наличие процедур запуска,  копирования и восстановления с участием оператора; 2) то же, без  участия оператора; 3) минимизируется необходимость в монтирова­  нии носителей для резервного копирования; 4) минимизируется не­  обходимость в средствах подачи и укладки бумаги при печати  5 Вмешательство оператора требуется только при запуске и заверше­  нии работы системы. Обеспечивается автоматическое восстановле­  ние работоспособности приложения после сбоев и ошибок

Количество возможных установок на различных платформах  0 Приложение рассчитано на установку у одного пользователя  1 Приложение рассчитано на много установок для строго стандартной  платформы (технические средства + программное обеспечение)  2 Приложение рассчитано на много установок для платформ с близ­  кими характеристиками  3 Приложение рассчитано на много установок для различных плат­  форм  4 То же, что в случаях 1 или 2, плюс наличие документации и планов  поддержки всех установленных копий приложения  5 То же, что в случае 3, плюс наличие документации и планов под­  держки всех установленных копий приложения  Гибкость 0 Ни одной из перечисленных возможностей 1 Любая одна из возможностей  2 Любые две из возможностей  3 Любые три из возможностей  4 Любые четыре из возможностей  5 Все пять возможностей  Определение значения фактора выравнивания (FAV)

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

1. Обмен данными (0 — продукт представляет собой автономное приложение; 5 — продукт обменивается данными по более, чем одному телекоммуникационному протоколу).

2. Распределенная обработка данных (0 — продукт не перемещает данные; 5 — распределенная обработка данных выполняется несколькими компонентами системы).

3. Производительность (0 — пользовательские требования по производительности не установлены; 5 — время отклика сильно ограничено критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа.

4. Ограничения по аппаратным ресурсам (0 — нет ограничений; 5 — продукт целиком должен функционировать на определенном процессоре и не может быть распределен).

5. Транзакционная нагрузка (0 — транзакций не много, без пиков; 5 — число транзакций велико и неравномерно, требуются специальные решения и инструменты).

6. Интенсивность взаимодействия с пользователем (0 — все транзакции обрабатываются в пакетном режиме; 5 — более 30% транзакций — интерактивные).

7. Эргономика (эффективность работы конечных пользователей) (0 — нет специальных требований; 5 — требования по эффективности очень жесткие).

8. Интенсивность изменения данных (ILF) пользователями (0 — не требуются; 5 — изменения интенсивные, жесткие требования по восстановлению).

9. Сложность обработки (0 — обработка минимальна; 5 — требования безопасности, логическая и математическая сложность, многопоточность).

10. Повторное использование (0 — не требуется; 5 — продукт разрабатывается как стандартный многоразовый компонент).

11. Удобство инсталляции (0 — нет требований; 5 — установка и обновление ПО производится автоматически).

12. Удобство администрирования (0 — не требуется; 5 — система автоматически самовосстанавливается).

13. Портируемость (0 — продукт имеет только 1 инсталляцию на единственном процессоре; 5 — система является распределенной и предполагает установку на различные «железо» и ОС).

14. Гибкость (0 — не требуется; 5 — гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме).

14 системных параметров (degree of influence, DI) оцениваются по шкале от 0 до 5. Расчет суммарного эффекта 14 системных характеристик (total degree of influence, TDI) осуществляется простым суммированием:

TDI = ∑ DI

Расчет значения фактора выравнивания производится по формуле

VAF = (TDI *0.01) + 0.65

Например, если, каждый из 14 системных параметров получил оценку 3, то их суммарный эффект составит TDI = 3 * 14 = 42. В этом случае значение фактора выравнивания будет: VAF = (42 * 0.01) + 0.65 = 1.07

После определения всех значений GSC и вычисления попра­вочного коэффициента VAF вычисляется итоговая оценка коли­чества функциональных точек (AFP):  AFP = UFP * VAF.

Валя как найти ufp?

Методика оценки трудоемкости разработки ПО на основе вариантов использования

Все действующие лица системы делятся на три типа

1)Простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом (API).

2) Среднее действующее лицо представляет либо внешнюю систему, взаимодействующую с данной системой посредством протокола наподобие TCP/IP, либо личность, пользующуюся текстовым интерфейсом (например, ASCII-терминалом).

3)Сложное действующее лицо представляет личность, пользующуюся графическим интерфейсом (GUI).

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

ОПРЕДЕЛЕНИЕ ВЕСОВЫХ ПОКАЗАТЕЛЕЙ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (UUCP)

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

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

ОПРЕДЕЛЕНИЕ ТЕХНИЧЕСКОЙ СЛОЖНОСТИ ПРОЕКТА

Техническая сложность проекта (TCF) вычисляется с учетом показателей технической сложности

ТСF= 0,6+(0,01*(сумм Ti*Vi))

Vi-вес

ОПРЕДЕЛЕНИЕ УРОВНЯ КВАЛИФИКАЦИИ РАЗРАБОТЧИКОВ

Уровень квалификации разработчиков (EF) вычисляется с учетом следующих показателей.

EF = 1,4 + (- 0,03 * (сум Fi * Vi))

ОЦЕНКА ТРУДОЕМКОСТИ ПРОЕКТА

В качестве начального значения предлагается использовать 20 человеко-часов на одну UCP. Эта величина может уточняться с учетом опыта разработчиков.

Рассмотрим показатели F1—F8 и определим, сколько показателей F1—F6 имеют значение меньше 3 и сколько показателей F7-F8 имеют значение больше 3.

Если общее количество меньше или равно 2, следует использовать 20 чел.-ч. на одну UCP, если 3 или 4—28. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск провала слишком высок.

Для системы регистрации получаем 28 чел.-ч. на одну UCP, таким образом, общее количество человеко-часов на весь проект равно 56,56*28 = 1583,68, что составляет 40 недель при 40-часовой рабочей неделе. Допустим, что команда разработчиков состоит из

четырех человек, и добавим 3 недели на различные непредвиденные ситуации, тогда в итоге получим 13 недель на весь проект. Опытные данные компании Rational Проект среднего размера (приблизительно 10 разработчиков, более чем 6—8 месяцев) может включать приблизительно 30 вариантов использования. Это соответствует тому, что средний вариант использования содержит 12 и СР, и каждая UCP требует 20-30 ч. Это означает общую трудоемкость 240-360 чел.-ч. на вариант использования. Таким образом, 30 вариантов использования потребуют приблизительно 9000 чел.-ч. (10 разработчиков в течение 6 месяцев). Однако прямой пропорции не существует: очень большой проект со 100 разработчиками и сроком 20 месяцев не начнется с 1000 вариантов

использования из-за проблем размерности. Использование описанной выше методики для простых и сложных систем хорошо согласуется с опытными данными компании Rational (приблизительно 150—350 ч. на один вариант использования). Самая простая система (весовой показатель UC = 5, А = 2, UUCP = 7) дает (при 20 чел.-ч. на UCP) приблизительно 140 чел.-ч. Сложная система (весовой показатель UC = 15, А = 3, UUCP = 18) дает приблизительно 360 чел.-ч. UCP=UUCP*TCF*EF

Методы оценки трудоемкости, основанные на экспертных оценках.

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

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

МЕТОД ДЕЛЬФИ

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

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

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

Общая структура организации работ по проектированию ИС

В организационном аспекте управление проектированием рассматриваются по уровням организационно-административной структуры с соответствующими правами и обязанностями субъектов процесса проектирования.

Организация работ по проектированию ЭИС определяется порядком взаимодействия между несколькими сторонами, участвующими в этом процессе: пользователем, заказчиком, администратором и разработчиком.

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

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

-формирует исходные данные для проектирования и обработки;

-определяет состав задач для автоматизации;

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

Заказчик – это ответственное лицо, под которым понимается организация или подразделение и которое выполняет функции:

-формирует требования к системе и ее частям;

-выдает техническое задание, финансирует разработку ЭИС;

-обеспечивает проведение комплекса мероприятий по ее созданию;

-проводит внедрение и прием проекта ЭИС.

При этом заказчик несет ответственность перед пользователем за соответствие состава и характеристик решаемых задач, режима функционирования ЭИС исходным данным пользователя, за сроки создания системы, правильность использования ресурсов в процессе проектирования.

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

Администратор несет ответственность перед пользователем за правильность результатов работы ЭИС и их своевременность, а перед заказчиком и разработчиком – за соблюдением условий эксплуатации, требований к технической документации.

Разработчик – это ответственное лицо (организация или подразделение), которое выполняет следующие функции:

-разрабатывает ЭИС по техническому заданию заказчика;

-принимает участие во внедрении;

-осуществляет сдачу проекта заказчику;

осуществляет авторское сопровождение проекта.

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

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

Организационные формы управления проектированием ИС

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

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

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

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

АИС-БУ как составная часть АИС содержит три основных компонента:

·информацию как предмет и продукт труда;

·средства, методы и способы переработки информации;

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

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

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

Подходы к классификации бухгалтерских программ

Регистры бухгалтерского учета

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

Учетные регистры различаются:

1) по внешнему оформлению: бухгалтерские книги, регистраторы, отдельные листы, карты, сведения.

2) по назначению: хронологические, систематические и комбинированные;

3) по содержанию: синтетические и аналитические;

4) по форме: односторонние, двусторонние, табличные и шахматные;

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

• наименование регистра;

• наименование экономического субъекта, составившего регистр;

• дата начала и окончания ведения регистра и (или) период, за который составлен регистр;

• хронологическая и (или) систематическая группировка объектов бухгалтерского учета;

• величина денежного измерения объектов бухгалтерского учета с указанием единицы измерения;

• наименования должностей лиц, ответственных за ведение регистра;

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

Становление сегмента бухгалтерских программ

В 1981 г. IBM представила первую модель персонального компьютера - IBM 5150.

системы обработки экономической информации с использованием ПК стали называться «Автоматизированные (компьютерные) информационные системы» (АИС)

Децентрализованная обработка учетных задач на рабочем месте бухгалтера.

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

2 период - Большее распространение ПК. Появление специализированных АРМ и более развитых многомашинных комплексов; решение вопросов обмена информации, синхронизации данных и пр. Появление первых локальных вычислительных сетей.

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

4 период - Распространение и развитие сетевых локальных вычислительных комплексов. Появление типовых отраслевых решений; переход от систем учёта к системам управления.

Появляется и развивается направление электронных справочно-правовых систем

1. Консультант-плюс

2. Гарант

3. Кодекс

4. Референт

Этап увлечения разработчиками «универсальными конструкторами» и открытыми системами и результаты их внедрения и эксплуатации привели к трём различным следствиям: Появление нового слоя специалистов (фирм-франчайзи), Упрощение работ по внедрению и сокращения сроков и стоимости внедрения , Формирование нового подхода к разработке программ.

Архитектура современных систем автоматизации бухгалтерского учета.

МНОГОСЛОЙНАЯ АРХИТЕКТУРА АВТОМАТИЗИРОВАННЫХ СИСТЕМ БУХГАЛТЕРСКОГО УЧЕТА (1 подход)

1 слой - Программное ядро – основа системы, реализующая системные функции.

2 слой- «Надстройка» - специальный язык программирования (обычно высокого уровня)..

3 слой - Слой параметрических, алгоритмических и прочих настроек.

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

БУХГАЛТЕРСКАЯ ИНФОРМАЦИОННАЯ СИСТЕМА - это система, обеспечивающая сбор, регистрацию и обработку информации о хозяйственной деятельности объекта с целью обеспечения аппарата управления необходимой информацией для принятия обоснованных управленческих решений.

1) ПРИНЦИП ПЕРВОГО ЛИЦА - определяет право принятия окончательного решения и порядок ответственности на различных уровнях управления.

2) ПРИНЦИП СИСТЕМНОГО ПОДХОДА - предполагает в процессе проектирования АСБУ проведение анализа объекта управления в целом и системы управления им, а также выработку общих целей и критериев функционирования объекта в условиях его автоматизации.

3) ПРИНЦИП НАДЕЖНОСТИ - обеспечивается с помощью различных способов, например, дублированием структурных элементов системы или их избыточности.

Классификация затрат внедрения систем автоматизации бухгалтерского учета.

1) стоимость лицензии;

2) стоимость внедрения;

3) стоимость обновления;

4) стоимость сопровождения

Выбор систем автоматизации бухгалтерского учета

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учет фактов хозяйственной жизни в автоматизированных системах бухгалтерского учета

Развитие интегрированных бизнес-приложений

MRP – системы планирования потребностей в материалах В основе функционирования подобных систем лежало понятие спецификации изделия (BOM – Bill Of Materials) и производственной программы (MPS- Master Production Schedule). Модуль планирования потребностей в мощностях (CRP – Capacity Requirements Planning). MRP (Material Requirements Planning) – автоматизированное планирование потребности сырья и материалов для производства; используется для описания компонента "производство";

MRP II (Manufacturing Resource Planning) – автоматизированное планирование всех производственных ресурсов предприятия (сырья, материалов, оборудования, его производительности, трудозатрат); используется для описания компонентов "производство", "логистика";

ERP (Enterprise Resource Planning) – автоматизация и оптимизация внутренних бизнес-процессов, планирование как материальных, так и финансовых ресурсов в масштабе предприятия; используется для описания компонентов "производство", "логистика", "финансы".

Системы управления внешней средой ближнего окружения (frontoffice):

• систем учета информации о конкурентах Бенчмаркинг (Benchmarking);

• систем учета и управления взаимоотношениями с потребителями или маркетинга отношений (CRM- Customer Relations Management);

- систем учета и управления взаимоотношениями с поставщиками или управления цепочками поставок (SCM- Supply Chain Management).

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

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

ERP включает в себя (но не ограничена):

• Управление производственными ресурсами (MRP II)

• Управление финансовыми ресурсами

• Управление трудовыми ресурсами

• Управление ремонтом

• Управление капитальным строительством

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

Простая электронная подпись.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

БЕЗОПАСНО:

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

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

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

НАДЕЖНО:

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

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

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

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

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

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

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

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

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

УДОБНО:

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

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

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