Система оценки качества знаний

 

 

Рис. 3.2. Информационная модель работы с оценками сотрудников.

 

Опишем набор таблиц, представленных на рисунке выше:

• Сотрудник. Описывает данные о сотруднике: его ФИО, и другие паспортные данные.
• Навык. Содержит привязку таблицы Справочник навыков и Качесвенный коэффициент к выбранному сотруднику. Качественный коэффициент берется из таблицы справочник качественных коэффициентов.
• Пользователь. Содержит информацию о пользователе, вошедшем в систему. Определяется в дополнение и типом, которые берется из таблицы с одноименным названием.
• Предполагаемая позиция и з/п. после анализа информации хранит данные о позиции и з/п сотрудника, которую компания может ему предложить.
• Отчет. Содержит аналитическую отчетную информацию по каждому аттестованному сотруднику.

3.5. Моделирование системных решений

 

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

Наиболее  распространенной диаграммой UML является диаграмма вариантов использования (use case). Она позволяет всем специалистам, занимающимся разработкой ПО увидеть, какие функции будут реализованы в системе, какое взаимодействие предполагается между пользователем системы и функциями и самим функциями. Остановимся на данном типе диаграммы более подробно.

Атрибутами  диаграммы вариантов использования  являются: актер – любая роль, которая будет иметь возможность  работать (взаимодействовать) в системе; вариант использования – является базовой единицей диаграммы, описывает определенный функционал системы на общем уровне, который будет реализован; отношения и связи – представлены на диаграмме стрелками, которые разное визуальное представление и этим определяют связь между актером и функцией, либо функцией-функцией [17].

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

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

 

 

Рис. 3.3. Диаграмма вариантов  использования для всех пользователей системы

 

Ее основными атрибутами являются следующие функции системы:

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

3.6. Выбор и обоснование технологий разработки

3.6.1. Обоснование принимаемых решений по используемым программным средствам

В работе над программным продуктом мы решили использовать технологию Hibernate.

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

Возможным решением этой задачи являются объектно-реляционные преобразователи (object-relation mappers, ORM), которые обеспечивают автоматическую синхронизацию между данными приложения в виде наборов связанных объектов и данными, хранящимися в системе управления базами данных (СУБД) в реляционном виде, т.е. в форме записей в нескольких таблицах, ссылающихся друг на друга с помощью внешних ключей.

Одним из наиболее широко применяемых и развитых в технологическом  плане объектно-реляционных преобразователей является Hibernate [18].

Базовая парадигма, лежащая в основе избранного Hibernate подхода, — это использование объектов обычных классов Java (быть может, оформленных в соответствии с требованиями спецификации JavaBeans — с четко выделенными свойствами) в качестве объектного представления данных приложения. Такой подход даже имеет название-акроним POJO (plain old Java objects, простые старые Java-объекты), призванное показать его отличие от сложных техник построения компонентов, похожих на EJB.

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

Также при разработке мы использовали MySQL. MySQL является относительно небольшой и быстрой реляционной СУБД основанной на традициях Hughes Technologies Mini SQL (mSQL).

Перечислим основные приятные стороны пакета MySQL:

• Многопоточность. Поддержка нескольких одновременных запросов.
• Оптимизация связей с присоединением многих данных за один проход.
• Записи фиксированной и переменной длины.
• ODBC драйвер в комплекте с исходником
• Гибкая система привилегий и паролей.
• До 16 ключей в таблице. Каждый ключ может иметь до 15 полей.
• Поддержка ключевых полей и специальных полей в операторе CREATE.
• Поддержка чисел длинной от 1 до 4 байт (ints, float, double, fixed), строк переменной длины и меток времени.
• Интерфейс с языками C и perl.
• Основанная на потоках, быстрая система памяти.
• Утилита проверки и ремонта таблицы ( isamchk).
• Все данные хранятся в формате ISO8859_1.
• Все операции работы со строками не обращают внимания на регистр символов в обрабатываемых строках.
• Псевдонимы применимы как к таблицам, так и к отдельным колонкам в таблице.
• Все поля имеют значение по умолчанию. INSERT можно использовать на любом подмножестве полей.
• Легкость управления таблицей, включая добавление и удаление ключей и полей [18].

3.6.2. Функциональное моделирование на основе системы Bpwin

Для моделирования и последующей  реализации приложения нам понадобилась система построения функциональной модели системы. Мы взяли методологию IDEF0 и поддерживающее ее приложение BPWin.

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках “аналитик-специалист”. Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих  решений родилась методология функционального  моделирования IDEF0.

Основные элементы и понятия IDEF0

Графический язык IDEF0 удивительно  прост и гармоничен. В основе методологии лежат четыре основных понятия.

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

Каждая из четырех  сторон функционального блока имеет своё определенное значение (роль), при этом:

• Верхняя сторона имеет значение “Управление” (Control);
• Левая сторона имеет значение “Вход” (Input);
• Правая сторона имеет значение “Выход” (Output);
• Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как  единого целого – одного функционального  блока с интерфейсными дугами, простирающимися за пределы рассматриваемой  области. Такая диаграмма с одним  функциональным блоком называется контекстной  диаграммой, и обозначается идентификатором “А-0”.

В процессе декомпозиции, функциональный блок, который в контекстной  диаграмме отображает систему как  единое целое, подвергается детализации  на другой диаграмме. Получившаяся диаграмма  второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели [19].

Мы разработали с помощью  этой методологии модель системы  оценки качества знаний. Часть этой модели приведена ниже на рис. 3.4 - 3.6.

 

 

Рис. 3.4. Контекстная диаграмма (уровень № 1).

 

 

Рис. 3.5. Функциональная модель (уровень № 2).

 

 

Рис. 3.6. Функциональная модель (уровень № 3).

 

 

 

 

ЗАКЛЮЧЕНИЕ

 

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