Автоматизация регистрации и мониторинга заявок от контрагентов
·
совместимость
данных; соответствие данных реальному состоянию объекта;
·
удобство и
увеличение скорости совместной обработки данных;
·
поддержка
целостности данных.
База данных (БД) — поименованная совокупность данных,
отражающая совокупность объектов и их отношений в рассматриваемой предметной
области. [3].
Основными способами организации БД являются создание
централизованных и распределенных БД. Основным критерием выбора способа
организации ИБ является достижение минимальных трудовых и стоимостных затрат на
проектирование структуры ИБ, программного обеспечения системы, системы ведения
файлов. На основании этих критериев и необходимостью обеспечения надежности
хранения данных выбран централизованный способ организации БД.
По способу установления связей между данными различают:
·
иерархическую;
·
сетевую;
·
реляционную
модель.
Основными компонентами любой из этих моделей являются файлы
(или таблицы).
Иерархические модели данных представляют собой графовую
модель с вершинами-таблицами. В моделях имеется один файл, который является
входом в структуру. Между файлами устанавливаются отношения соподчиненности. У
файла может быть одна исходная вершина и несколько подчиненных. Основной тип
отношений - 1:М.
В сетевых моделях любой файл может быть точкой входа в
систему, и связан с произвольным числом других файлов отношениями типа 1:1, 1:М
и М:М.
Наиболее широкое распространение получила реляционная модель
данных. При такой организации вся информация представлена в виде таблиц (файлов
БД) и отношений. Таблицы являются совокупностью записей (строк, кортежей).
Между отношениями (таблицами) существуют связи типа 1:М, М:М. Каждое отношение
имеет ключ - это поле записи (атрибут) однозначно идентифицирующее ее. Данное свойство
реляционной модели данных исключает дублирование информации, ускоряет поиск и
доступ к конкретным данным.
Принятый в реляционной модели подход к структурированию и
целостности данных позволяет удобно организовать и упорядочить процесс
проектирования и реализации сложных баз данных, а реляционные операции обладают
мощными возможностями управления данными и их обработки.
Учитывая все преимущества реляционных моделей данных для
представления информации, обрабатываемой при решении задачи целесообразно использовать
реляционную модель БД.
Программное обеспечение (ПО) включает
совокупность программ, реализующих функции и задачи ИС и обеспечивающих
устойчивую работу комплексов технических средств. В состав программного
обеспечения входят общесистемные и специальные программы, а также
инструктивно-методические материалы по применению средств программного
обеспечения.
К общесистемному (общему) программному обеспечению относятся
программы, рассчитанные на широкий круг пользователей и предназначенные для
организации вычислительного процесса и выполнения часто встречающихся вариантов
обработки информации. Они позволяют расширить функциональные возможности ЭВМ,
автоматизировать планирование очередности вычислительных работ, а также
автоматизировать работу программистов. Специальное (функциональное) программное
обеспечение представляет собой совокупность программ, разрабатываемых при
создании ИТ конкретного функционального назначения. Оно включает пакеты
прикладных программ, осуществлявших организацию данных и их обработку при
решении функциональных задач ИС [3].
При выборе комплекса технических средств для разработки
системы, одним из важнейших критерием является выбор операционной системы.
Операционная система управляет техническими средствами компьютера, поддерживает
запуск и выполнение тех или иных программ и приложений, обеспечивает защиту
данных, выполняет различные сервисные функции. Каждая программа пользуется
средствами, предоставляемыми операционной системой. Таким образом, выбор
операционной системы очень важен, так как он определяет набор программ и формат
исполняемых файлов, а также их взаимодействие с операционной системой.
На компьютерах с архитектурой x86, используемых в качестве
рабочих мест пользователей, чаще всего применяются следующие операционные
системы:
- операционные системы семейства Windows от фирмы Microsoft
(Windows 95/98/Me, Windows NT4.0/2000/XP),
- операционные системы Linux/BSD семейства (UNIX подобные) от различных фирм – разработчиков (Red Hat, Debian, Novel, Mandrake soft, Gentoo,
Slackware, IBM, Oracle,
NetBSD, OpenBSD, FreeBSD)
[13].
Для разработки программного приложения автоматизированной
обработки выбор той или иной операционной системы не повлияет на
функциональность системы по причине того, что при реализации алгоритмов
программного приложения не требуется использования каких-либо специфических
функций операционной системы. Оба типа операционных систем позволяют разрабатывать
программный продукт без потери его функциональности, по причине наличия
программных сред (языков программирования) для обоих типов операционных систем
[14].
Все из вышеперечисленных операционных систем содержат
интерфейсы межсетевого взаимодействия, что позволяет использовать программное
приложение в сети, для обмена данными и параллельной работы нескольких копий
программного приложения с одними исходными данными. Оба типа операционных
систем содержат в себе качественный интерфейс пользователя, что также позволяет
производить разработку программного приложения для любой из этих операционных
систем.
В качестве операционной среды для разработки и применения
программы была выбрана операционная система семейства Windows, в частности
операционная система Windows Vista.
Этот выбор обусловлен тем, что на сегодняшний день Windows Vista является одной из наиболее распространенных
операционных систем. Операционная система Windows Vista обеспечивает стабильность работы, предоставляя
пользователям возможность сосредоточиться на выполняемой работе.
Одним из важных
требований, предъявляемых к проектированию информационных систем,
эксплуатируемых совместно на технологической базе весьма ограниченных
возможностей, является большая их однородность, позволяющая обеспечить
совместимость, мобильность, переносимость.
Выбор системы
управления баз данных (СУБД) представляет собой сложную многопараметрическую
задачу и является одним из важных этапов при разработке приложений баз данных.
Выбранный программный продукт должен удовлетворять как текущим, так и будущим
потребностям предприятия, при этом следует учитывать финансовые затраты на
приобретение необходимого оборудования, самой системы, разработку необходимого
программного обеспечения на ее основе, а также обучение персонала. Кроме того,
необходимо убедиться, что новая СУБД способна принести предприятию реальные
выгоды.
Наиболее
простой подход при выборе СУБД основан на оценке того, в какой мере
существующие системы удовлетворяют основным требованиям создаваемого проекта
информационной системы. Более сложным и дорогостоящим вариантом является
создание испытательного проекта на основе нескольких СУБД и последующий выбор
наиболее подходящего из кандидатов. Но и в этом случае необходимо ограничивать
круг возможных систем, опираясь на некие критерии отбора. В данном случае можно
выделить несколько групп критериев:
·
Моделирование
данных
·
Особенности
архитектуры и функциональные возможности
·
Контроль работы
системы
·
Особенности
разработки приложений
·
Производительность
·
Надежность
·
Требования к
рабочей среде
·
Смешанные
критерии
Основным принципом выбора СУБД следует считать определение
программного продукта, в наибольшей мере соответствующего предъявляемым
требованиям. Эту задачу решить не очень просто. Во-первых, к СУБД предъявляется
большое число требований, которые с течением времени изменяются, во-вторых,
СУБД имеют большое число параметров, что затрудняет их сравнение. Кроме того,
информация о СУБД часто носит рекламный характер, не позволяющий сделать
правильное суждение.
Процедуру выбора СУБД следует проводить в три этапа:
·
На качественном
уровне оценить предлагаемые программные продукты на предмет пригодности;
·
Оценка
технических характеристик отобранных систем;
·
Оценка
производительности программных продуктов.
К числу основных показателей пригодности программных
продуктов относятся:
·
вид программного
продукта;
·
категории
пользователей (профессиональные программисты, администраторы БД,
квалифицированные пользователи, разрабатывающие приложения, конечные
пользователи, различные комбинации перечисленных категорий);
·
удобство и
простота использования (понятные процедуры установки программных продуктов,
удобный и унифицированный интерфейс конечного пользователя, простота выполнения
обычных операций: создания БД, навигации, модификации, подготовки данных,
выполнения запросов и отчетов и ряда других; наличие интеллектуальных подсистем
подсказок, помощи в процессе работы и обучения, включая примеры);
·
модель
представления данных. Наиболее распространенной является реляционная модель
данных. Перспективными являются модели с объектной ориентацией, поскольку они
обладают большими возможностями отражения семантики предметной области;
·
качество средств
разработки. При оценке качества средств разработки учитывается следующее: возможности
создания пользовательских интерфейсов, мощность языка создания программ,
автоматизация разработки различных объектов: экранных форм, отчетов, запросов.
Предпочтение отдается системам, имеющим полнофункциональные генераторы и
обеспечивающим удобство работы пользователя;
·
качество средств
защиты и контроля корректности базы данных. Доступ к функциям защиты должен
предусматриваться на уровне средств разработки программ и на уровне
пользователя. К важнейшим функциям контроля корректности относятся: обеспечение
уникальности записей БД по первичному ключу, автоматический контроль
целостности связей между таблицами во время выполнения операций обновления,
вставки и удаления записей, проверка корректности значений в БД;
·
качество
коммуникационных средств. При оценке качества коммуникационных средств обращают
внимание на следующие свойства программных продуктов:
·
поддержку сетевых
протоколов,
·
поддержку
стандартных интерфейсов с БД,
·
наличие средств
групповой работы с информацией БД,
·
способность использовать
и модифицировать БД других форматов без импортирования или преобразования;
·
фирма –
разработчик. Солидность фирмы-разработчика пакета, как правило, дает следующие
преимущества:
·
высокое качество
продукта,
·
наличие
документации и методических материалов
·
наличие «горячей
линии» для консультаций по возникающим проблемам
При выборе продукта следует обратить внимание на дату его
появления. В качестве показателей «благополучия» можно использовать: твердое
финансовое положение, перспективная динамика развития аппаратно-программных
средств, годовой оборот, численность состава, объем продаж и т.д. - стоимость.
На стоимость программных продуктов в основном влияют вид программного продукта
и фирма – разработчик. Стоимость полнофункциональных СУБД обычно колеблется в
пределах $ 500 - $ 1000. Общая стоимость включает в себя стоимость прикладного
инструментария, средств настройки конфигурации системы, администрирования БД и
сопровождения. Иногда общая стоимость крупных систем, построенных на базе
реляционных БД, достигает миллионов долларов. Основным фактором, определяющим
общую стоимость системы, чаще всего является число поддерживаемых
пользователей.
На уровне технических характеристик разнообразие СУБД еще
больше, чем на качественном уровне. К техническим характеристикам относятся:
·
общие параметры
(операционная среда, потребность в оперативной памяти, ограничения на
максимальный объем БД и др.);
·
ограничения на
операции над данными;
·
типы данных;
·
возможности
средств формулировки и выполнения запросов;
·
работа в
многопользовательских средах;
·
инструментальные
средства разработки приложений;
·
импорт и экспорт.
Оценка производительности производится методом тестирования с
помощью эталонных тестов из набора AS3AP (ANSI SQL Standard Scalable and
Portable). В них контролируется широкий спектр часто встречающихся операций БД
и моделируются однопользовательские и многопользователь-ские среды.
Ниже, в
таблице 1.10. приведена сравнительная таблица трех распространенных систем
управления базами данных, конкурирующих на рынке программного обеспечения
по основным показателям.
Таблица 1.8 Сравнение СУБД
Показатели
|
Microsoft
SQL Server 2008
|
MySQL
5.1
|
PostgreSQL
8.4
|
Поддерживаемые
операционные системы |
Windows
Desktop/Server |
Windows
Desktop/Server , Linux, Unix, Mac |
Windows1 Desktop/S22erver,
Linux, Unix, 2Mac |
Условии
лицензирования |
Коммерческий
продукт с закрытым исходным кодом. Есть бесплатная версия
с ограничением оперативной памяти до 4 Гб. |
Коммерческая
лицензия и GNU GPL. |
Лицензия
BSD Open Source. |
Наличие
предустановленных драйверов в ОС семейства Windows |
Да |
Нет |
Нет |
Наличие
драйверов ODBC, JDBC, ADO.NET |
Да |
Да |
Да |
Поддержка
репликации |
Да,
встроенная и разных типов. Но внесение структурных изменений после
начала репликаци — очень сложный процесс. |
Да, включая
mater-master репликацию. |
Да,
но с помощью сторонних продуктов с открытым исходным кодом.
Репликация всех типов. |
Возможность
писать хранимые функции на разных языках программирования |
Да,
теоретически на любом языке, поддерживающим CLR, например
VisualBasic.NET, C#, IronPython, но сначала надо скомпилировать код
в библиотеку dll. |
Нет (кроме
C и Pl/SQL) |
Да,
наиболее полная поддержка из всех рассматриваемых. |
Возможность
создавать пользовательские аггрегированные функции |
Да —
любой .NET язык, кроме TRANSACT SQL. |
Да, только
на С |
Да —
на PL language и встроенных C, SQL, PLPgSQL. |
Поддержка
даты и времени |
Да |
Да
(но без временной зоны) |
Да |
Аутентификация |
Средствами
БД и ActiveDirectory |
Средствами
БД |
Много
разных методов, включающих предыдущие |
Разграничение
доступа к столбцам |
Да |
Да |
Да |
Поддержка
DISTINCT ON |
Нет |
Нет |
Да |
Поддержка
WITH ROLLUP |
Да |
Да |
Да |
Поддержка
WITH CUBE |
Да |
Нет |
Нет |
Поддержка функций OVER..PARTITION BY |
Да |
Нет |
Да, причем
лучше, чем в MS SQL |
Поддержка
рекурсивных запросов |
Да |
Нет |
Да |
Производительность
планировщика запросов для сложных запросов |
Средняя
(умеет параллельные запросы «из коробки») |
Очень
хорошая |
Плохая |
Таким образом, для проекта, рассматриваемого в данном
дипломном проекте наиболее приемлема СУБД MS SQL.
Для реализации приложения
пользователя выбран язык программирования ASP.
ASP (англ. Active Server Pages — «активные серверные страницы») — технология,
разработанная компанией Microsoft, позволяющая легко создавать приложения для World Wide Web. ASP
работает на платформе операционных систем линии Windows NT и на веб-сервере Microsoft IIS. ASP не является языком программирования
— это лишь технология предварительной обработки, позволяющая подключать
программные модули во время процесса формирования веб-страницы. Относительная
популярность ASP основана на простоте используемых
языков сценариев (VBScript или JScript) и возможности использования внешних
COM-компонентов.
Технология ASP получила своё развитие в виде ASP.NET — новой технологии создания веб-приложений,
основанной на платформе Microsoft .NET.
ASP.NET — технология создания
веб-приложений и веб-сервисов от компании Майкрософт. Она является составной
частью платформы Microsoft .NET и развитием более старой технологии Microsoft
ASP. На данный момент последней версией этой технологии является ASP.NET 4.0b.
ASP.NET внешне во многом сохраняет
схожесть с более старой технологией ASP, что позволяет разработчикам
относительно легко перейти на ASP.NET. В то же время внутреннее устройство
ASP.NET существенно отличается от ASP, поскольку она основана на платформе .NET
и, следовательно, использует все новые возможности, предоставляемые этой
платформой.
Хотя ASP.NET
берёт своё название от старой технологии Microsoft ASP, она значительно от неё отличается. Microsoft полностью перестроила ASP.NET, основываясь на Common Language Runtime (CLR),
который является основой всех приложений Microsoft .NET. ASP.NET имеет преимущество в скорости по
сравнению со скриптовыми технологиями, так как при первом обращении код
компилируется и помещается в специальный кэш, и впоследствии только
исполняется.
Вместе с тем следует учитывать, что
указанное преимущество не всегда может быть реализовано. Это связано с тем, что
на скорость работы реального проекта влияют множество факторов. [11]
2. Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного
цикла проекта автоматизации
Понятие жизненного цикла является одним из базовых понятий
методологии проектирования информационных систем. Жизненный цикл информационной
системы представляет собой непрерывный процесс, начинающийся с момента принятия
решения о создании информационной системы и заканчивается в момент полного
изъятия ее из эксплуатации.
Жизненный цикл информационной системы охватывает все стадии и этапы ее
создания, сопровождения и развития:
·
исследование
предметной области с последующим формированием функциональной и информационной
моделей объекта, для которого предназначена информационная система;
·
проектирование
системы, заключающееся в разработке проектных решений, удовлетворяющих всем
требованиям ТЗ;
·
разработку
системы (в том числе программирование и тестирование прикладных программ на
основании проектных спецификаций подсистем, выделенных на стадии
проектирования);
·
тестирование
информационной системы и выявление сбоев с последующим их устранением;
·
эксплуатацию
системы и ее сопровождение;
·
развитие системы.
Жизненный цикл протекает в соответствии с выбранной моделью ЖЦ.
Существует
целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы
разработки.
Среди
наиболее известных стандартов можно выделить следующие:
·
ГОСТ 34.601-90 -
распространяется на автоматизированные системы и устанавливает стадии и этапы
их создания. Кроме того, в стандарте содержится описание содержания работ на
каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей
степени соответствуют каскадной модели жизненного
цикла .
·
ISO/IEC
12207:1995 - стандарт на процессы и организацию жизненного
цикла. Распространяется на все виды заказного ПО. Стандарт не содержит
описания фаз, стадий и этапов .
·
Custom
Development Method (методика Oracle) по разработке прикладных информационных
систем - технологический материал, детализированный до уровня заготовок
проектных документов, рассчитанных на использование в проектах с применением
Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все
работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast
Track) или "облегченного подхода", рекомендуемых в случае малых
проектов.
·
Rational Unified
Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы:
начало, исследование, построение и внедрение. Каждая фаза может быть разбита на
этапы (итерации), в результате которых выпускается версия для внутреннего или
внешнего использования. Прохождение через четыре основные фазы называется
циклом разработки, каждый цикл завершается генерацией версии системы. Если
после этого работа над проектом не прекращается, то полученный продукт
продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP -
это создание и сопровождение моделей на базе UML.
·
Microsoft
Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ,
проектирование, разработка, стабилизация, является итерационной, предполагает
использование объектно-ориентированного моделирования. MSF в сравнении с RUP в
большей степени ориентирована на разработку бизнес-приложений.
·
Extreme
Programming (XP). Экстремальное программирование (самая новая среди
рассматриваемых методологий) сформировалось в 1996 году. В основе методологии
командная работа, эффективная коммуникация между заказчиком и исполнителем в
течение всего проекта по разработке ИС, а разработка ведется с использованием
последовательно дорабатываемых прототипов.
·
Стандарт ISO/IEC
серии 15288
В стандарте ISO/IEC 12207 не предлагается конкретной модели жизненного
цикла и методов разработки, его рекомендации являются общими для любых моделей
жизненного цикла. Под моделью обычно понимается структура, определяющая
последовательность выполнения и взаимосвязи процессов, действий и задач на
протяжении жизненного цикла.
В настоящее время существует две основные модели жизненного цикла – это
каскадная и спиральная модели. В каскадной модели процесс разработки идет
поэтапно, шаг за шагом. Переход к следующему этапу происходит только после
завершения предыдущего. В спиральной модели разработка проходит по нарастающей.
На начальном этапе разрабатывается система с высоким уровнем абстракции, а на
последующих витках эта разработка все больше и больше конкретизируется. Для
жизненного цикла текущего проекта была выбрана каскадная модель, так как для
разрабатываемой системы больше подходит поэтапная разработка. Переход к
следующему этапу происходит только после завершения всех работ на предыдущем
этапе (Рис. 2.1), включая подготовку полного пакета документации, достаточной
для того, чтобы разработка могла быть продолжена другой группой разработчиков и
есть возможность планирования сроков завершения работ и затрат на их
выполнение.
Рисунок 2.1 Каскадная схема разработки ПО.
Каскадный метод хорошо подходит для построения систем, где в
самом начале разработки можно достаточно точно и полно сформулировать все
требования, с тем, чтобы предоставить разработчикам свободу реализовывать их
как можно лучше с технической точки зрения. Однако в случае, если в середине
разработки вскрываются ошибки, допущенные в начале, то приходится прибегать к
энтраверсии проекта и реальная схема каскадной модели приобретает другой вид (Рис.
2.2). Таким образом, каскадный метод более всего подходит к конкретной разработке.
Рисунок 2.2 Реальный процесс
разработки ПО по каскадной схеме.
2.1.2 Ожидаемые риски на этапах
жизненного цикла и их описание
Любой проект по созданию
информационной системы предприятия всегда включает множество задач, связанных с
общим управлением проектом, разработкой ПО, проектированием ИС, внедрением,
каждая из которых сама по себе является проектом с присущими ему особенностями.
Поэтому в ходе разработки существуют различные риски.
Риски заказчика связаны с
неполным достижением целей проекта и не эффективно израсходованными средствами,
а риски исполнителя - с возможностью резкого превышения фактической
себестоимости работ по сравнению с плановой. Необходимость ведения параллельных
и подчас принципиально отличающихся по своему характеру работ приводит к тому,
что многократно возрастает уровень риска проекта.
Наиболее характерные
риски и методы из минимизации приведены в таблице 2.1
Таблица 2.1 Возможные
риски проекта и способы их минимизации
Виды
рисков/варианты менеджмента рисков
|
Снижение
видов риска
|
Снижение
вероятности возникновения риска
|
Риски,
связанные с масштабом проекта |
Детальный
анализ каждого этапа работ, взаимодействия участников, организации работ |
Детально
проработанная программа качества, отработанное управление конфигурацией
проекта, специальные процедуры взаимодействия участников |
Риски,
связанные с недостаточным опытом в сфере ИТ |
Проведение
обучения пользователей, включая руководство, соблюдение технологий работы |
Разработка
и утверждение концепции проекта на возможно более ранней его стадии |
Технические
риски проекта |
Строгий
отбор проектной команды по квалификационным критериям. Обучение участников
проекта технологии проектных работ, инструментальным средствам |
Использование
стандартов предприятия на проектные работы, разработка стандартов проекта |
Организационные
риски проекта |
Обучение
участников проекта (курс "управление проектом"), тренинги команды,
как можно более полная формализация деятельности |
Включение
в команду администратора проекта, детальное распределение ролей в проекте |
Операционные
риски проекта |
Многократное
тестирование созданных продуктов, тщательная экспертиза документов |
Строгое
выполнение процедур программы качества |
2.2 Информационное обеспечение
задачи
2.2.1 Информационная модель и её
описание
Информационная модель представляет собой схему движения
входных, промежуточных и результативных потоков и функций предметной области.
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по обработке
данных и формирование конкретных выходных документов. Информационная модель
представлена на рис. 2.3.
Рисунок 2.3
Информационная модель системы
В соответствии с представленной информационной моделью
менеджер заполняет справочник Состояние проектов. Далее, используя данные
справочников Клиенты, Сотрудники, Города, Фирмы, состояния проектов, изменяет
содержание таблицы Проекты. На основании таблицы Проекты и Справочника
Состояние проектов менеджер получает экранные формы выходных документов, таких,
как список проектов и список этапов выполнения проектов.
2.2.2
Используемые
классификаторы и системы кодирования
В составе
информационного обеспечения рассматриваемого комплекса задач важное место
отводится классификаторам экономической информации: обеспечить сжатие
призначной части (идентификатора) показателей, а, следовательно, и сократить
объем хранимой информации в ЭВМ и время на поиск информации,
необходимой для решения задач, облегчить обработку информации позволяют
классификация и кодирование информации.
Классификатор — это документ, с помощью которого
осуществляется формализованное описание экономической информации в ЭИС,
содержащий наименования объектов, наименования классификационных группировок и
их кодовые обозначения.[9] В зависимости от применения они делятся на три
группы:
1.
общегосударственные
классификаторы, используемые во всех отраслях и на всех уровнях управления для
повсеместного и одинакового обозначения объектов;
2.
отраслевые
(ведомственные) классификаторы, используемые в пределах определенной отрасли
(ведомства);
3.
локальные,
используемые в пределах организации или группы организации.
Для полной
формализации экономической информации недостаточно простой классификации,
поэтому проводят процедуру кодирования.
Кодирование —
это процесс присвоения условных обозначений объектам и классификационным
группам по соответствующей системе кодирования. [9]
Система
кодирования — это совокупность правил обозначения объектов и группировок с
использованием кодов. [9]
Код — это
условное обозначение объектов или группировок в виде знака или группы знаков в
соответствии с принятой системой. Все системы кодирования можно сгруппировать в
два подмножества: регистрационных и классификационных систем кодирования.[9]
Требования, которым
должны удовлетворять разрабатываемые классификаторы, следующие:
·
полнота охвата
объектов и признаков классификации каждым классификатором;
·
согласованность
признаков деления множеств объектов с алгоритмами обработки экономической
информации;
·
взаимная
однозначность наименований объектов и их кодовых обозначений;
·
простота
кодирования и возможность автоматизации классификации и кодирования;
·
возможность
увязки с другими классификаторами и системами обозначений;
·
эффективность
использования классификатора при обработке информации.
В системе используется следующие виды системы кодирования,
указанные в таблице 2.2.
Таблица 2.2 Используемые
системы кодирования
Кодируемое
множество объектов |
Длина
кода |
Мощность
кода |
Система
кодирования |
Система
классификации |
Вид
классификатора |
Клиенты |
4 |
9999 |
Порядковая |
Отсутствует |
Локальный |
Проекты |
4 |
9999 |
Порядковая |
Отсутствует |
Локальный |
Состояния
проектов |
2 |
99 |
Порядковая |
Отсутствует |
Локальный |
1) Классификатор клиентов
Страницы: 1, 2, 3, 4, 5, 6
|