Реферат стандартизация разработки программных средств
Обновлено: 05.07.2024
Электронная очередь – это комплекс программно-аппаратных средств, предназначенных для оптимизации и формализации управления потоком людей (очередью). Очередь позволяет в значительной степени улучшить работу любой организации, в которой требуется постоянный прием клиентов. Распределение посетителей между операторами позволяет ускорять процесс обслуживания, а также исключает простой в работе персонала.
Внедрение электронной очереди в организации позволяют менеджерам зала в процессе работы системы и обслуживания клиентов оперативно вносить коррективы в работу операторов, разрабатывать новые методики облуживания, более эффективно выделять категории обслуживания клиентов.
В системе электронной очереди существует возможность гибко настроить работу операторов и, таким образом, равномерно разделить поток клиентов между всеми работающими в данный момент операторами.
Содержание
ВВЕДЕНИЕ 3
1. АНАЛИЗ СРЕДЫ 5
2. ПОЯСНИТЕЛЬНАЯ ЗАПИСКА 16
2.1. Список исполнителей 16
2.2. Техническое задание 17
2.2.1. Назначение и область применения программного изделия. 17
2.2.2. Основание для разработки 17
2.2.3. Требования заказчика к ПИ 17
2.3. Календарный план разработки 21
2.3.1. Общий план разработки 21
2.3.2. Индивидуальный план разработки 22
2.4. Документация разработки 23
2.4.1. Технический проект 23
2.4.2. Подготовка к разработке 25
2.4.3. Программная реализация 29
2.4.4. Тестирование системы 36
2.5. Эксплуатационная документация 41
2.5.1. Руководство системного программиста 41
2.5.2. Руководство программиста. 43
2.5.3. Руководство оператора. 46
2.5.4. Документация по установке и сопровождению системы 49
ЗАКЛЮЧЕНИЕ 52
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ. 54
Приложения.
Прикрепленные файлы: 1 файл
Курсовик РиСПСиИТ.docx
Федеральное агентство по образованию
Хрянин Евгений Леонидович
студент 3 курса, специальности
Хреев Николай Владимирович
2011 год
Содержание
ВВЕДЕНИЕ
Электронная очередь – это комплекс программно-аппаратных средств, предназначенных для оптимизации и формализации управления потоком людей (очередью). Очередь позволяет в значительной степени улучшить работу любой организации, в которой требуется постоянный прием клиентов. Распределение посетителей между операторами позволяет ускорять процесс обслуживания, а также исключает простой в работе персонала.
Внедрение электронной очереди в организации позволяют менеджерам зала в процессе работы системы и обслуживания клиентов оперативно вносить коррективы в работу операторов, разрабатывать новые методики облуживания, более эффективно выделять категории обслуживания клиентов.
В системе электронной очереди существует возможность гибко настроить работу операторов и, таким образом, равномерно разделить поток клиентов между всеми работающими в данный момент операторами. Программные комплексы позволяют разделить поток людей по категориям, чтобы к разным операторам подходили на обслуживание только те клиенты, категорию которых этот оператор в данный момент обслуживает. К примеру, 3 оператора занимающиеся одновременно консультированием, приемом платежей и подписанием новых договоров с клиентами, будут работать менее эффективно, чем разделенные на категории. Ведь больше всего будут обращаться именно с оплатой платежей, менее за консультацией, но эта операция чаще всего занимает мало времени, ну и реже всего будут обращаться для подписания договоров, а эта процедура далеко не быстрая.
При этом система электронной очереди ведет постоянную статистику, и управляющие всегда могут наблюдать за своими посетителями, средним временем простоя в очереди, и время обслуживания у оператора, тем самым разработать более эффективную схему сервиса.
Области применения электронной очереди встречаются повсеместно:
- операционные залы банков
- центры выплат страховых компаний
- клиентские центры операторов сотовой связи
- налоговые и регистрационные службы
- пенсионные фонды
- медицинские центры
- нотариальные и адвокатские конторы
- посольства и консульские учреждения
- авиа-, авто- и железнодорожные кассы
- государственные учреждения
- Электронная очередь
- Сенсорные киоски
- Светодиодные табло
- Электронный паркинг
- Светодиодное освещение
- Модуль сервера электронной очереди
- Модуль регистратора для сенсорного терминала и администратора офиса
- Модуль визуализации
- ПО голосового сопровождения вызова, гонг
- ПО медиасервера для вывода состояния очереди на LCD-мониторы
- Программное обеспечение Сервер СУО "Мета-Прайм", располагающее возможностями: Текущее состояние зала, Статистика по выбранному интервалу времени, централизованное управление. ПО – это основной компонент системы управления очередью, выполняющий все основные функции управления. Это мощный программный продукт, обладающий широкими возможностями:
- Поддержка практически неограниченного количества рабочих мест;
- Возможность использования иерархического меню;
- Множество различных отчетов: по очередям и операциям, по рабочим местам и пользователям, по времени ожидания и обслуживания посетителей, отображения списка билетов, количества билетов в час и многое другое.
Схема работы системы:
Рассмотрим преимущества и недостатки данного решения:
Компания занимается производством систем контроля подлинности, оборудования для криминалистики, техники для банков, а также системы электронная очередь.
· разработке программных средств с использованием современных алгоритмических языков программирования и информационных технологи;
· стандартизации основных этапов жизненного цикла программных средств;
· стандартизации документирования программных средств;
· обеспечение надежности и качества функционирования программных средств;
· использование методов тестирования программного обеспечения.
Задачами курсового проекта являются:
· детально анализировать объект управления;
· поставить задачу, определить все ее функции;
· разработать структуру БД, нормативно-справочной и оперативной информации;
· разработать этапы жизненного цикла программных средств (ПС) в соответствии со стандартами;
· отладить и внедрить задачу;
· рассчитать качественную характеристику ПС;
· создать пользовательский интерфейс и документацию к нему.
1 Проектирование экономической информационной системы
![]()
Да (Совпадения не допускаются)
Число десятичных знаков
Число десятичных знаков
Краткий формат даты
Да (Совпадения не допускаются)
Число десятичных знаков
Остаток денег в кассе
Число десятичных знаков
Количество денег в кассе
![]()
Рисунок 2 - Добавление нового источника данных
![]()
Рисунок 3 - Создание нового источника на основе драйвера MicrosoftAccess
![]()
Рисунок 4 - Установка драйвера
В данном проекте используются компоненты:
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, DB, DBTables, Grids, DBGrids, ExtCtrls, DBCtrls, StdCtrls;
![]()
Рисунок 5- Установленные компоненты DataSource ,Table, DBGrid, MainMenu
![]()
Рисунок 6-Кнопки DBNavigator: добавление записи, удаление, редактирование, обновление и сохранение записей
2. Модели оценки характеристик качества и надежности ПО
Размерно-ориентированные метрики. Функционально- ориентированные метрики. Пример применения метрик. Достоинства и недостатки размерно – ориентированных и функционально-ориентированных метрик.
Размерно-ориентированные метрики
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC – оценках (LinesOfCode). LOC - оценка – это количество строк в программном продукте.
Исходные данные для расчета этих метрик сводятся в таблицу (табл.2).
Исходные данные для расчета LOC- метрик
На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества проекта:
Производительность = Длина / Затраты =0,073/1=0,073 (тыс.LOC/чел.-мес.);
Качество = Ошибки / Длина=11/0,073=150,68 (Единиц/тыс. LOC);
Удельная стоимость = Стоимость /Длина=50/0,073=684,93 (тыс.$/LOC);
Достоинства размерно-ориентированных метрик:
· просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
· зависимы от языка программирования;
· требуют исходных данных, которые трудно получить на начальной стадии проекта;
· не приспособлены к непроцедурным языкам программирования.
Функционально-ориентированные метрики
Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC – оценки при этом рассматривается не размер, а функциональность или полезность продукта.
Используется 5 информационных характеристик.
1. Количество внешний вводов . Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.
3. Количество внешних запросов . Под запросами понимают диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует вычислений. Подсчитываются все запросы – каждый учитывается отдельно.
4. Количество внутренних логических файлов . Подсчитываются все логические файлы (т.е. логические группы данных, которые могут быть частью базы данных или отдельным файлом).
5. Количество внешних интерфейсных файлов . Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.
Выводы, вводы, запросы относятся к категории транзакция . Транзакция – это элементарный процесс, различаемый пользователем и перемещающий данные между внешней средой и программным приложением. В своей работе транзакции используют внутренние и внешние файлы. Приняты следующие определения.
Внешний ввод – элементарный процесс, перемещающий данные из внешней среды в приложение. Данные могут поступать с экрана ввода или из другого приложения.
Внешний вывод - элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, посылаемые другим приложениям. Отчеты и файлы создаются на основе внутренних логических файлов и внешних интерфейсных файлов. Дополнительно этот процесс может использовать вводимые данные, их образуюткритерии поиска и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные поступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле.
Внутренний логический файл – распознаваемая пользователем группа логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы.
Внешний интерфейсный файл – распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении.
Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга. Для транзакций ранжирование основано на количестве ссылок и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов-элементов записей и типов элементов данных, входящих в файл.
Тип элемента-записи – подгруппа элементов данных, распознаваемая пользователем в пределах файла.
Тип элемента данных – уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. Примеры элементов данных для различных характеристик приведены в табл.4, 5 и содержат правила учета элементов из графического интерфейса пользователя (ГИП).
Примеры элементов данных
Вводимые элементы: поле, используемое для списка, щелчок мыши.
Выводимые элементы: отображаемые на экране поля.
Правила учета элементов данных из ГИП
Элемент данных Правило учета Группа радиокнопок Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных Группа флажков (переключатели) Так как в группе пользователь может выбрать несколько флажков, каждый флажок считают элементом данных Командные кнопки Командная кнопка может определять действия добавления, изменения, запроса. Кнопка ОК может вызвать транзакции. Кнопка Next может быть входным элементом запроса или вызвать другую транзакцию. Списки Список может быть внешним запросом, но результат запроса может быть элементом данных внешнего вида. Например, ГИП для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (Добавить, Изменить, Удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка).
Обычно этому экрану ГИП соответствует несколько транзакций. Типичный экран включает несколько внешний запросов, сопровождающих внешний ввод.
Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл.5-9 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4.
Ранг и оценка сложности внешних вводов
Ссылки на файлы Элементы данных 1-4 5-15 >15 0-1 Низкий (3) Низкий (3) Средний (4) 2 Низкий (3) Средний (4) Высокий (6) >2 Средний (4) Высокий (6) Высокий (6) Ранг и оценка сложности внешних выводов
Ссылки на файлы Элементы данных 1-4 5-19 >19 0-1 Низкий (4) Низкий (4) Средний (5) 2-3 Низкий (4) Средний (5) Высокий (7) >3 Средний (5) Высокий (7) Высокий (7) Ранг и оценка сложности внешних запросов
Ссылки на файлы Элементы данных 1-4 5-19 >19 0-1 Низкий (3) Низкий (3) Средний (4) 2-3 Низкий (3) Средний (4) Высокий (6) >3 Средний (4) Высокий (6) Высокий (6) Ранг и оценка сложности внутренних логических файлов
Ссылки на файлы Элементы данных 1-19 20-50 >50 0-1 Низкий (7) Низкий (7) Средний (10) 2-5 Низкий (7) Средний (10) Высокий (15) >5 Средний (10) Высокий (15) Высокий (15) Ранг и оценка сложности внешних интерфейсных файлов
Ссылки на файлы Элементы данных 1-19 20-50 >50 0-1 Низкий (5) Низкий (5) Средний (7) 2-5 Низкий (5) Средний (7) Высокий (10) >5 Средний (7) Высокий (10) Высокий (10) После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (FunctionPoints).
Исходные данные для расчета сводятся в табл. 10. В таблицу заносится количественное значение характеристики каждого вида (по всем уровням сложности). Места подстановки значений отмечены прямоугольником (этот символ играет роль метки - заполнителя). Количественные значения характеристик умножаются на числовые оценки сложности. Полученные в каждой строке значения суммируются, давая полное значение для данной характеристики. Эти полные значения суммируются по вертикали, формируя общее количество.
Исходные данные для расчета FP – метрик
Имя характеристики Ранг, сложность, количество Низкий Средний Высокий Итого Внешние вводы 3*3=9 3*4=12 3*6=18 =29 Внешние выводы 6*4=24 6*5=30 6*7=42 =96 Внешние запросы 0*3=0 0*4=0 0*6=0 =0 Внутренние логические файлы 1*7=7 1*10=10 1*15=15 =32 Внешние интерфейсные файлы 1*5=5 1*7=7 1*10=10 =22 Общее количество =179 Количество функциональных указателей вычисляется по формуле:
FP=Общее количество*(0,65+0,01*4)=208*(0,65+0,01*4)=143,52, (1)
Где Fi – коэффициент регулировки сложности (I=1..14).
Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.11).
После вычисления FP на его основе формируются метрики производительности, качества и другие оценки.
Производительность = ФункцУказатель / Затраты =143,52/1=143,52 (FP/чел.-мес.);
Качество = Ошибки / ФункцУказатель=11/143,52=0,08 (Единиц/FP);
Удельная Стоимость = Стоимость / ФункцУказатель=50/143,52=0,39 (Тыс.$/FP);
Определение системных параметров приложения
№ Системный параметр Описание 1 Передачи данных Сколько средств данных требуется для передачи или обмена информацией с приложением или системой? 2 Распределенная обработка данных Как обрабатываются распределенные данные и функции обработки? 3 Производительность Нуждается ли пользователь в фиксации времени ответа или производительности? 4 Распространенность используемой конфигурации Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? 5 Скорость транзакций Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)? 6 Оперативный ввод данных Какой процент информации нужно вводить в режиме онлайн? 7 Эффективность работы конечного пользователя Приложение проектировалось для обеспечения эффективной работы конечного пользователя? 8 Оперативное обновление Как много внутренних файлов обновляется в онлайновой транзакции? 9 Сложность обработки Выполняет ли приложение интенсивную логическую или математическую обработку? 10 Повторная используемость Приложение разрабатывалось для удовлетворения требований одного или многих пользователей? 11 Легкость инсталляции Насколько трудны преобразования и инсталляция приложения? 12 Легкость эксплуатации Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления? 13 Разнообразные условия размещения Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций? 14 Простота изменений Была ли спроектирована, разработана и поддержана в приложении простота изменения? Область применения функциональных указателей – коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики свойств (FeaturesPoints). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО.
Для вычисления указателя свойств добавляется одна характеристика – количество алгоритмов . Алгоритм здесь определяется как ограниченная программа вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 12.
Исходные данные для расчета указателя свойств
№ Характеристика Количество Сложность Итого 1 Вводы 3 *4 =12 2 Выводы 6 *5 =30 3 Запросы 0 *4 =0 4 Логические файлы 1 *7 =7 5 Интерфейсные файлы 1 *7 =7 6 Количество алгоритмов 5 *3 =15 Общее количество =71 После заполнения таблицы по формуле (1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей.
Достоинства функционально-ориентированных метрик:
· не зависят от языка программирования;
· Легко вычисляются на любой стадии проекта.
Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.
FP – оценки легко пересчитать в LOC– оценки. Как показано в табл.13, результаты пересчета зависят от языка программирования, используемого для реализации ПО.
Пересчет FP – оценок в LOC – оценки
Язык программирования Количество операторов на 1 FP Ассемблер 320 С 128 Паскаль 90 С++ 64 Java 53 Visual Basic 32 Visual С++ 34 Delphi Pascal 29 HTML 3 15 LISP 64 Prolog 64 Список источников литературы
1. Диго С.М. Базы данных: проектирование и использование. Учебное пособие для вузов. – Москва.: Финансы и статистика, 2005.
2. Кузин А.В., Демин В.М.Разработка баз данных в системе MicrosoftAccess: Учебник – Учебник – м.: Форум: Инфра-М, 2005г.
3. Тиори Т., Фрай Дж. : Проектирование структур баз данных. М, 1985.
4. Гофман В., Хомоненко А.: Delphi 6 в подлиннике. СПб,2001.
5. Пестрнков В. М., Маслобоев А. Н.: Delphi на примерах.,2005.
6. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем., Под редакцией Тельнова Ю.Ф.. – Москва.: Финансы и статистика, 2003.
7. Дунаев С. В. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования – М.: Диалог – МИФИ, 1999. – 416 с.
8. Сигнор Р., Стегман М. О. Использование ODBC для доступа к базам данных – М.: БИНОМ, 1995. – 384 с.
![Разработка и стандартизация программных средств 1]()
В данном проекте используются компоненты:
- Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, DB, DBTables, Grids, DBGrids, ExtCtrls, DBCtrls, StdCtrls;
![Разработка и стандартизация программных средств 2]()
Рисунок 5- Установленные компоненты DataSource ,Table, DBGrid, MainMenu
![Разработка и стандартизация программных средств 3]()
Рисунок 6-Кнопки DBNavigator: добавление записи, удаление, редактирование, обновление и сохранение записей
2. Модели оценки характеристик качества и надежности ПО
Размерно-ориентированные метрики. Функционально- ориентированные метрики. Пример применения метрик. Достоинства и недостатки размерно – ориентированных и функционально-ориентированных метрик.
Размерно-ориентированные метрики
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC – оценках (LinesOfCode).
LOC — оценка – это количество строк в программном продукте.
Исходные данные для расчета этих метрик сводятся в таблицу (табл.2).
Проект Затраты, чел.-мес. Стоимость тыс. $ КLOC, тыс. LOC Ошибки Количество человек А01 1 50 0,073 18 11 1 На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества проекта:
Достоинства размерно-ориентированных метрик:
- широко распространены;
- просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
- зависимы от языка программирования;
- требуют исходных данных, которые трудно получить на начальной стадии проекта;
- не приспособлены к непроцедурным языкам программирования.
Функционально-ориентированные метрики
Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC – оценки при этом рассматривается не размер, а функциональность или полезность продукта.
Используется 5 информационных характеристик.
Количество внешний вводов
Количество внешних выводов
Количество внешних запросов
Количество внутренних логических файлов
Количество внешних интерфейсных файлов
Внешний ввод
Внешний вывод —
Внешний запрос –
Внутренний логический файл –
Внешний интерфейсный файл –
Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга. Для транзакций ранжирование основано на количестве ссылок и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов-элементов записей и типов элементов данных, входящих в файл.
Тип элемента-записи – подгруппа элементов данных, распознаваемая пользователем в пределах файла.
Тип элемента данных – уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. Примеры элементов данных для различных характеристик приведены в табл.4, 5 и содержат правила учета элементов из графического интерфейса пользователя (ГИП).
Примеры элементов данных
Вводимые элементы: поле, используемое для списка, щелчок мыши.
Выводимые элементы: отображаемые на экране поля.
Правила учета элементов данных из ГИП
Элемент данных Правило учета Группа радиокнопок Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных Группа флажков (переключатели) Так как в группе пользователь может выбрать несколько флажков, каждый флажок считают элементом данных Командные кнопки Командная кнопка может определять действия добавления, изменения, запроса. Кнопка ОК может вызвать транзакции. Кнопка Next может быть входным элементом запроса или вызвать другую транзакцию. Списки Список может быть внешним запросом, но результат запроса может быть элементом данных внешнего вида. Например, ГИП для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (Добавить, Изменить, Удалить).
В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка).
Обычно этому экрану ГИП соответствует несколько транзакций. Типичный экран включает несколько внешний запросов, сопровождающих внешний ввод.
Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл.5-9 (числовая оценка указана в круглых скобках).
Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4.
Ссылки на файлы Элементы данных 1-4 5-15 >15 0-1 Низкий (3) Низкий (3) Средний (4) 2 Низкий (3) Средний (4) Высокий (6) >2 Средний (4) Высокий (6) Высокий (6) Ранг и оценка сложности внешних выводов
Ссылки на файлы Элементы данных 1-4 5-19 >19 0-1 Низкий (4) Низкий (4) Средний (5) 2-3 Низкий (4) Средний (5) Высокий (7) >3 Средний (5) Высокий (7) Высокий (7) Ранг и оценка сложности внешних запросов
Ссылки на файлы Элементы данных 1-4 5-19 >19 0-1 Низкий (3) Низкий (3) Средний (4) 2-3 Низкий (3) Средний (4) Высокий (6) >3 Средний (4) Высокий (6) Высокий (6) Ранг и оценка сложности внутренних логических файлов
Ссылки на файлы Элементы данных 1-19 20-50 >50 0-1 Низкий (7) Низкий (7) Средний (10) 2-5 Низкий (7) Средний (10) Высокий (15) >5 Средний (10) Высокий (15) Высокий (15) Ранг и оценка сложности внешних интерфейсных файлов
Ссылки на файлы Элементы данных 1-19 20-50 >50 0-1 Низкий (5) Низкий (5) Средний (7) 2-5 Низкий (5) Средний (7) Высокий (10) >5 Средний (7) Высокий (10) Высокий (10) После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (FunctionPoints).
Исходные данные для расчета сводятся в табл. 10. В таблицу заносится количественное значение характеристики каждого вида (по всем уровням сложности).
Места подстановки значений отмечены прямоугольником (этот символ играет роль метки — заполнителя).
Количественные значения характеристик умножаются на числовые оценки сложности. Полученные в каждой строке значения суммируются, давая полное значение для данной характеристики. Эти полные значения суммируются по вертикали, формируя общее количество.
Исходные данные для расчета FP – метрик
Имя характеристики Ранг, сложность, количество Низкий Средний Высокий Итого Внешние вводы 3*3=9 3*4=12 3*6=18 =29 Внешние выводы 6*4=24 6*5=30 6*7=42 =96 Внешние запросы 0*3=0 0*4=0 0*6=0 =0 Внутренние логические файлы 1*7=7 1*10=10 1*15=15 =32 Внешние интерфейсные файлы 1*5=5 1*7=7 1*10=10 =22 Общее количество =179 Количество функциональных указателей вычисляется по формуле:
FP=Общее количество*(0,65+0,01*4)=208*(0,65+0,01*4)=143,52, (1)
Где F i – коэффициент регулировки сложности (I=1..14).
Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.11).
После вычисления FP на его основе формируются метрики производительности, качества и другие оценки.
Производительность = ФункцУказатель / Затраты =143,52/1=143,52 (FP/чел.-мес.);
- Качество = Ошибки / ФункцУказатель=11/143,52=0,08 (Единиц/FP);
- Удельная Стоимость = Стоимость / ФункцУказатель=50/143,52=0,39 (Тыс.$/FP);
Определение системных параметров приложения
№ Системный параметр Описание 1 Передачи данных Сколько средств данных требуется для передачи или обмена информацией с приложением или системой? 2 Распределенная обработка данных Как обрабатываются распределенные данные и функции обработки? 3 Производительность Нуждается ли пользователь в фиксации времени ответа или производительности? 4 Распространенность используемой конфигурации Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? 5 Скорость транзакций Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)? 6 Оперативный ввод данных Какой процент информации нужно вводить в режиме онлайн? 7 Эффективность работы конечного пользователя Приложение проектировалось для обеспечения эффективной работы конечного пользователя? 8 Оперативное обновление Как много внутренних файлов обновляется в онлайновой транзакции? 9 Сложность обработки Выполняет ли приложение интенсивную логическую или математическую обработку? 10 Повторная используемость Приложение разрабатывалось для удовлетворения требований одного или многих пользователей? 11 Легкость инсталляции Насколько трудны преобразования и инсталляция приложения? 12 Легкость эксплуатации Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления? 13 Разнообразные условия размещения Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций? 14 Простота изменений Была ли спроектирована, разработана и поддержана в приложении простота изменения? метрики свойств
Исходные данные для расчета указателя свойств
№ Характеристика Количество Сложность Итого 1 Вводы 3 *4 =12 2 Выводы 6 *5 =30 3 Запросы 0 *4 =0 4 Логические файлы 1 *7 =7 5 Интерфейсные файлы 1 *7 =7 6 Количество алгоритмов 5 *3 =15 Общее количество =71 После заполнения таблицы по формуле (1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей.
Достоинства функционально-ориентированных метрик:
- не зависят от языка программирования;
- Легко вычисляются на любой стадии проекта.
Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.
FP – оценки легко пересчитать в LOC– оценки. Как показано в табл.13, результаты пересчета зависят от языка программирования, используемого для реализации ПО.
Пересчет FP – оценок в LOC – оценки
Язык программирования Количество операторов на 1 FP Ассемблер 320 С 128 Паскаль 90 С++ 64 Java 53 Visual Basic 32 Visual С++ 34 Delphi Pascal 29 HTML 3 15 LISP 64 Prolog 64 Заключение
1. Диго С.М. Базы данных: проектирование и использование. Учебное пособие для вузов. – Москва.: Финансы и статистика, 2005.
2. Кузин А.В., Демин В.М.Разработка баз данных в системе MicrosoftAccess: Учебник – Учебник – м.: Форум: Инфра-М, 2005г.
3. Тиори Т., Фрай Дж. : Проектирование структур баз данных. М, 1985.
4. Гофман В., Хомоненко А.: Delphi 6 в подлиннике. СПб,2001.
5. Пестрнков В. М., Маслобоев А. Н.: Delphi на примерах.,2005.
6. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем., Под редакцией Тельнова Ю.Ф.. – Москва.: Финансы и статистика, 2003.
7. Дунаев С. В. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования – М.: Диалог – МИФИ, 1999. – 416 с.
8. Сигнор Р., Стегман М. О. Использование ODBC для доступа к базам данных – М.: БИНОМ, 1995. – 384 с.
9. Фленов М.Е. Библия Delphi. – СПб.: БХВ-Петербург, 2004. – 880 с.
Примеры похожих учебных работ
Проектирование и реализация хранилища данных для анализа бизнес деятельности компании
. компаниям требуется организовать работу с информацией наилучшим образом. Поэтому возникла необходимость в создании специализированных систем хранения данных и дополнительных средств анализа поступающей информации. Система хранения данных состоит из .
Модернизация структуры базы данных на основе анализа требований предприятия
. модернизации, будут вам доступны. К примеру, файл SQL скриптов базы данных. В рамках работы над данным проектом нам доступна база данных . нотации UML. Применительно к нашей работе, учитывая небольшую структуру и достаточно простую иерархию .
К вопросу о металлической связи в плотнейших упаковках химических элементов
. структурой его кристаллической решетки, учитывая необходимость направленных связей (химия) и наличие обобществленных электронов (физика), . гипотетическая плотность упаковки возможна при наличии 12 связей. Но реальна ли такая возможность? Внешние .
Устройства хранения данных
. магнитного покрытия дисков и потере данных и работоспособности устройства. Диски вращаются постоянно, а скорость . ленточные устройства. 2.Магнитные дисковые накопители П ринцип работы магнитных запоминающих устройств основаны на способах хранения .
Силовые кабели низкого напряжения (до 1 кВ)
. годы ориентируются на применение кабелей с медными токопроводящими жилами, так как алюминиевые жилы кабелей (особенно для уличного . обозначают тип защитного покрова. Например, кабель марки СГ имеет медную жилу, бумажную пропитанную изоляцию, свинцовую .
Элементы геодезических разбивочных работ
. технологических осей оборудования. На этом этапе требуется наибольша точность (в отдельных случаях - доли миллиметра). Нормы точности на разбивочные работы задаются в проекте или в нормативных документах (СНиП, .
· разработке программных средств с использованием современных алгоритмических языков программирования и информационных технологи;
· стандартизации основных этапов жизненного цикла программных средств;
· стандартизации документирования программных средств;
· обеспечение надежности и качества функционирования программных средств;
· использование методов тестирования программного обеспечения.
Задачами курсового проекта являются:
· детально анализировать объект управления;
· поставить задачу, определить все ее функции;
· разработать структуру БД, нормативно-справочной и оперативной информации;
· разработать этапы жизненного цикла программных средств (ПС) в соответствии со стандартами;
· отладить и внедрить задачу;
· рассчитать качественную характеристику ПС;
· создать пользовательский интерфейс и документацию к нему.
1 Проектирование экономической информационной системы
![]()
Да (Совпадения не допускаются)
Число десятичных знаков
Число десятичных знаков
Краткий формат даты
Да (Совпадения не допускаются)
Число десятичных знаков
Остаток денег в кассе
Число десятичных знаков
Количество денег в кассе
![]()
Рисунок 2 - Добавление нового источника данных
![]()
Рисунок 3 - Создание нового источника на основе драйвера MicrosoftAccess
![]()
Рисунок 4 - Установка драйвера
В данном проекте используются компоненты:
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, DB, DBTables, Grids, DBGrids, ExtCtrls, DBCtrls, StdCtrls;
![]()
Рисунок 5- Установленные компоненты DataSource ,Table, DBGrid, MainMenu
![]()
Рисунок 6-Кнопки DBNavigator: добавление записи, удаление, редактирование, обновление и сохранение записей
2. Модели оценки характеристик качества и надежности ПО
Размерно-ориентированные метрики. Функционально- ориентированные метрики. Пример применения метрик. Достоинства и недостатки размерно – ориентированных и функционально-ориентированных метрик.
Размерно-ориентированные метрики
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC – оценках (LinesOfCode). LOC - оценка – это количество строк в программном продукте.
Исходные данные для расчета этих метрик сводятся в таблицу (табл.2).
Исходные данные для расчета LOC- метрик
На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества проекта:
Производительность = Длина / Затраты =0,073/1=0,073 (тыс.LOC/чел.-мес.);
Качество = Ошибки / Длина=11/0,073=150,68 (Единиц/тыс. LOC);
Удельная стоимость = Стоимость /Длина=50/0,073=684,93 (тыс.$/LOC);
Достоинства размерно-ориентированных метрик:
· просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
· зависимы от языка программирования;
· требуют исходных данных, которые трудно получить на начальной стадии проекта;
· не приспособлены к непроцедурным языкам программирования.
Функционально-ориентированные метрики
Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC – оценки при этом рассматривается не размер, а функциональность или полезность продукта.
Используется 5 информационных характеристик.
1. Количество внешний вводов . Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.
3. Количество внешних запросов . Под запросами понимают диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует вычислений. Подсчитываются все запросы – каждый учитывается отдельно.
4. Количество внутренних логических файлов . Подсчитываются все логические файлы (т.е. логические группы данных, которые могут быть частью базы данных или отдельным файлом).
5. Количество внешних интерфейсных файлов . Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.
Выводы, вводы, запросы относятся к категории транзакция . Транзакция – это элементарный процесс, различаемый пользователем и перемещающий данные между внешней средой и программным приложением. В своей работе транзакции используют внутренние и внешние файлы. Приняты следующие определения.
Внешний ввод – элементарный процесс, перемещающий данные из внешней среды в приложение. Данные могут поступать с экрана ввода или из другого приложения.
Внешний вывод - элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, посылаемые другим приложениям. Отчеты и файлы создаются на основе внутренних логических файлов и внешних интерфейсных файлов. Дополнительно этот процесс может использовать вводимые данные, их образуюткритерии поиска и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные поступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле.
Внутренний логический файл – распознаваемая пользователем группа логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы.
Внешний интерфейсный файл – распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении.
Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга. Для транзакций ранжирование основано на количестве ссылок и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов-элементов записей и типов элементов данных, входящих в файл.
Тип элемента-записи – подгруппа элементов данных, распознаваемая пользователем в пределах файла.
Тип элемента данных – уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. Примеры элементов данных для различных характеристик приведены в табл.4, 5 и содержат правила учета элементов из графического интерфейса пользователя (ГИП).
Примеры элементов данных
Вводимые элементы: поле, используемое для списка, щелчок мыши.
Выводимые элементы: отображаемые на экране поля.
Правила учета элементов данных из ГИП
Элемент данных Правило учета Группа радиокнопок Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных Группа флажков (переключатели) Так как в группе пользователь может выбрать несколько флажков, каждый флажок считают элементом данных Командные кнопки Командная кнопка может определять действия добавления, изменения, запроса. Кнопка ОК может вызвать транзакции. Кнопка Next может быть входным элементом запроса или вызвать другую транзакцию. Списки Список может быть внешним запросом, но результат запроса может быть элементом данных внешнего вида. Например, ГИП для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (Добавить, Изменить, Удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка).
Обычно этому экрану ГИП соответствует несколько транзакций. Типичный экран включает несколько внешний запросов, сопровождающих внешний ввод.
Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл.5-9 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4.
Ранг и оценка сложности внешних вводов
Ссылки на файлы Элементы данных 1-4 5-15 >15 0-1 Низкий (3) Низкий (3) Средний (4) 2 Низкий (3) Средний (4) Высокий (6) >2 Средний (4) Высокий (6) Высокий (6) Ранг и оценка сложности внешних выводов
Ссылки на файлы Элементы данных 1-4 5-19 >19 0-1 Низкий (4) Низкий (4) Средний (5) 2-3 Низкий (4) Средний (5) Высокий (7) >3 Средний (5) Высокий (7) Высокий (7) Ранг и оценка сложности внешних запросов
Ссылки на файлы Элементы данных 1-4 5-19 >19 0-1 Низкий (3) Низкий (3) Средний (4) 2-3 Низкий (3) Средний (4) Высокий (6) >3 Средний (4) Высокий (6) Высокий (6) Ранг и оценка сложности внутренних логических файлов
Ссылки на файлы Элементы данных 1-19 20-50 >50 0-1 Низкий (7) Низкий (7) Средний (10) 2-5 Низкий (7) Средний (10) Высокий (15) >5 Средний (10) Высокий (15) Высокий (15) Ранг и оценка сложности внешних интерфейсных файлов
Ссылки на файлы Элементы данных 1-19 20-50 >50 0-1 Низкий (5) Низкий (5) Средний (7) 2-5 Низкий (5) Средний (7) Высокий (10) >5 Средний (7) Высокий (10) Высокий (10) После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (FunctionPoints).
Исходные данные для расчета сводятся в табл. 10. В таблицу заносится количественное значение характеристики каждого вида (по всем уровням сложности). Места подстановки значений отмечены прямоугольником (этот символ играет роль метки - заполнителя). Количественные значения характеристик умножаются на числовые оценки сложности. Полученные в каждой строке значения суммируются, давая полное значение для данной характеристики. Эти полные значения суммируются по вертикали, формируя общее количество.
Исходные данные для расчета FP – метрик
Имя характеристики Ранг, сложность, количество Низкий Средний Высокий Итого Внешние вводы 3*3=9 3*4=12 3*6=18 =29 Внешние выводы 6*4=24 6*5=30 6*7=42 =96 Внешние запросы 0*3=0 0*4=0 0*6=0 =0 Внутренние логические файлы 1*7=7 1*10=10 1*15=15 =32 Внешние интерфейсные файлы 1*5=5 1*7=7 1*10=10 =22 Общее количество =179 Количество функциональных указателей вычисляется по формуле:
FP=Общее количество*(0,65+0,01*4)=208*(0,65+0,01*4)=143,52, (1)
Где Fi – коэффициент регулировки сложности (I=1..14).
Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.11).
После вычисления FP на его основе формируются метрики производительности, качества и другие оценки.
Производительность = ФункцУказатель / Затраты =143,52/1=143,52 (FP/чел.-мес.);
Качество = Ошибки / ФункцУказатель=11/143,52=0,08 (Единиц/FP);
Удельная Стоимость = Стоимость / ФункцУказатель=50/143,52=0,39 (Тыс.$/FP);
Определение системных параметров приложения
№ Системный параметр Описание 1 Передачи данных Сколько средств данных требуется для передачи или обмена информацией с приложением или системой? 2 Распределенная обработка данных Как обрабатываются распределенные данные и функции обработки? 3 Производительность Нуждается ли пользователь в фиксации времени ответа или производительности? 4 Распространенность используемой конфигурации Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? 5 Скорость транзакций Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)? 6 Оперативный ввод данных Какой процент информации нужно вводить в режиме онлайн? 7 Эффективность работы конечного пользователя Приложение проектировалось для обеспечения эффективной работы конечного пользователя? 8 Оперативное обновление Как много внутренних файлов обновляется в онлайновой транзакции? 9 Сложность обработки Выполняет ли приложение интенсивную логическую или математическую обработку? 10 Повторная используемость Приложение разрабатывалось для удовлетворения требований одного или многих пользователей? 11 Легкость инсталляции Насколько трудны преобразования и инсталляция приложения? 12 Легкость эксплуатации Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления? 13 Разнообразные условия размещения Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций? 14 Простота изменений Была ли спроектирована, разработана и поддержана в приложении простота изменения? Область применения функциональных указателей – коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики свойств (FeaturesPoints). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО.
Для вычисления указателя свойств добавляется одна характеристика – количество алгоритмов . Алгоритм здесь определяется как ограниченная программа вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 12.
Исходные данные для расчета указателя свойств
№ Характеристика Количество Сложность Итого 1 Вводы 3 *4 =12 2 Выводы 6 *5 =30 3 Запросы 0 *4 =0 4 Логические файлы 1 *7 =7 5 Интерфейсные файлы 1 *7 =7 6 Количество алгоритмов 5 *3 =15 Общее количество =71 После заполнения таблицы по формуле (1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей.
Достоинства функционально-ориентированных метрик:
· не зависят от языка программирования;
· Легко вычисляются на любой стадии проекта.
Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.
FP – оценки легко пересчитать в LOC– оценки. Как показано в табл.13, результаты пересчета зависят от языка программирования, используемого для реализации ПО.
Пересчет FP – оценок в LOC – оценки
Язык программирования Количество операторов на 1 FP Ассемблер 320 С 128 Паскаль 90 С++ 64 Java 53 Visual Basic 32 Visual С++ 34 Delphi Pascal 29 HTML 3 15 LISP 64 Prolog 64 Список источников литературы
1. Диго С.М. Базы данных: проектирование и использование. Учебное пособие для вузов. – Москва.: Финансы и статистика, 2005.
2. Кузин А.В., Демин В.М.Разработка баз данных в системе MicrosoftAccess: Учебник – Учебник – м.: Форум: Инфра-М, 2005г.
3. Тиори Т., Фрай Дж. : Проектирование структур баз данных. М, 1985.
4. Гофман В., Хомоненко А.: Delphi 6 в подлиннике. СПб,2001.
5. Пестрнков В. М., Маслобоев А. Н.: Delphi на примерах.,2005.
6. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем., Под редакцией Тельнова Ю.Ф.. – Москва.: Финансы и статистика, 2003.
7. Дунаев С. В. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования – М.: Диалог – МИФИ, 1999. – 416 с.
8. Сигнор Р., Стегман М. О. Использование ODBC для доступа к базам данных – М.: БИНОМ, 1995. – 384 с.
Читайте также:
Процесс внедрения электронной очереди в организации достаточно прост и чаще всего требует мало дополнительных материальных затрат. Типовая система требует наличие сервера для базы данных, а также администраторского управляющего приложения, для этого подойдет сервер уже работающий в организации, так как система не очень требовательна к вычислительным ресурсам. Операторам устанавливается часть системы, отвечающая за вызов клиентов – эта часть достаточно легкая и чаще всего дополнительной модернизации компьютера для её установки не требуется. Дополнительным будет покупка в организацию большого телевизора, либо монитора, для объявления следующего вызываемого клиента в очереди. Организация пунктов выдающих номерки и позволяющих встать в очередь, возможна на базе списанных старых компьютеров организации, либо покупкой специализированных терминалов.
Развертывание комплекса обычно производится опытными специалистами-разработчиками, а для дальнейшей работы и управления комплексом не требуется особых знаний и умений, чаще всего требуется базовая компьютерная грамотность.
АНАЛИЗ СРЕДЫ
Прежде чем приступить к созданию собственной системы электронной очереди, был проведен анализ существующих на рынке систем.
Для проведения анализа был произведен поиск подходящих систем на рынке и выделено несколько из них.
Данная компания работает на российском рынке информационных технологий с 2001 года и позиционирует себя как признанный лидер в области автоматизированных систем управления потоками. В активе компании опыт внедрения множества проектов в различных сферах.
У данной компании представлено несколько продуктов на рынке:
В базовый комплект комплекса входит:
В самый расширенный пакет могут входить следующие компоненты:
