Обзор и анализ инструментальных средств обеспечения кадровой деятельности
На сегодняшний день, с интенсивным развитием информационных технологий и их активным использованием во всех отраслях человеческой деятельности, наблюдается существенный рост объемов обрабатываемой в компьютерных системах информации. С увеличением объемов информации растет необходимость в разработке эффективных средств ее обработки, хранения, обеспечения доступа нескольким пользователям и т. д. Автоматизированные информационные системы управления кадрами являются мощным инструментом по учету работников, графиков их отпусков, автоматизации документооборота, а также в получении различной аналитической информации и решении других задач.
На современном этапе рынок информационных технологий предлагает большое количество инструментальных средств разработки информационных систем, позволяющих оперативно решать проблемы управления кадрами, повышать эффективность бизнес-процессов в организациях любого уровня и различных направлений деятельности. Разнообразие таких программных продуктов позволяет выбрать оптимальное инструментальное средство, позволяющее удовлетворить потребности конечного пользователя в требуемом объеме.
При выборе инструментальных средств разработки информационных систем управления кадрами необходимо учитывать такие актуальные для разработчика критерии как: стоимость инструментального средства разработки, поддержка крупных баз данных, поддержка многопользовательского режима, компактность. Стоимость инструментального средства непосредственно влияет на стоимость конечного продукта, кроме того платные программы предлагают достаточно широкий спектр дополнительных инструментов и сервисов при разработке и сопровождении конечного продукта. Такой критерий как поддержка крупных баз данных является достаточно критичным при разработке программных продуктов для организации кадровой деятельности на крупных предприятиях, где необходимы обеспечение гибкости и масштабируемости базы данных. Кроме того важной является поддержка многопользовательского режима, то есть наличия в разрабатываемой системе внутренних блокировок, например, позволяющих одновременно одному из пользователей вносить данные в базу, а другому просматривать ее. Условие компактности должно обеспечиваться нормализацией данных в автоматизированной системе. Ведь с ростом данных, требуется все больше пространства для их хранения и дальнейшей обработки. Соответственно увеличение объема информации ведет к увеличению капитальных вложений в устройства для ее хранения.
|
|
Кроме того, при создании баз данных (БД) важным является выбор такого инструментального средства разработки, который бы удовлетворял такие потребности конечных пользователей как: актуальность информации для организации; производительность БД, обеспечивающая получение требуемых данных за короткое время; гибкость и возможность подстройки под пользователя; масштабируемость при реорганизации и расширении предметной области; кроссплатформенность; целостность базы данных; удобство использования.
Примеры инструментальных средств разработки информационных систем, используемых кадровыми службами:
|
|
· Visual FoxPro
· Firebird
· Microsoft Office Access
· Visual Basic Application.
· Microsoft SQL Server
Средства автоматизированного проектирования концептуальной модели
Средства автоматизированного проектирования концептуальной модели привлекают к себе в настоящее время большой интерес и используются в процессе создания структуры базы данных и интерфейса пользователя для доступа к данным.
Причина применения этих средств состоит в использовании в подавляющем большинстве реальных разработок баз данных спиральной модели жизненного цикла программного обеспечения, что предусматривает последовательное создание нескольких версий программного обеспечения. Каждая следующая версия включает в себя предыдущую (возможно, не полностью) и является ответом на замечания пользователя, полученные в результате тестирования предыдущей версии. При создании баз данных первая модель программного обеспечения, к сожалению, очень редко является удачной. Чаще всего заказчик отвергает первую версию, так как она недостаточно полно отвечает его требованиям. Причина такой ситуации заключается в том, что заказчик не может сразу, до создания начальной версии программы, четко и полно сформулировать свои требования. Обычно после получения первого варианта программного обеспечения заказчик выдвигает дополнительные требования, которые нельзя реализовать в рамках созданной базы данных. Это вынуждает разработчиков вносить изменения в структуру базы данных, а также, соответственно, винтерфейс пользователя для доступа к базе данных. Таких итераций может быть несколько до момента получения решения, адекватного запросам заказчика. Но даже после получения удовлетворительного решения процесс разработки базы данных не завершается. Жизнь не стоит на месте, и запросы заказчика меняются с течением времени. Часть этих изменений можно реализовать без изменения структуры базы данных, изменяя только интерфейс пользователя, другие же требуют изменения и интерфейса, и структуры базы данных. Надо заметить, что подобные изменения являются очень болезненными – работа по их внесению может оказаться трудоемкой и, что самое неприятное, потребовать замены большого количества отлаженного программного кода. Иными словами, замененный код был написан впустую, на самом деле его не нужно было писать.
|
|
Таким образом, создание работоспособной базы данных можно условно разделить на три этапа – проектирование базы данных, в процессе которого создаются рабочие прототипы, кодирование – создание структур баз данных и законченного интерфейса пользователя и сопровождение готовой базы данных.
Основная идея применения средств автоматизированного проектирования баз данных заключается в том, что процесс ручного кодирования начинается только после окончания процесса проектирования. На стадии проектирования схема базы данных иинтерфейс пользователя для доступа к базе данных создаются автоматически, исходя из описания концептуальной модели, с помощью так называемых CASE-средств (Computer Aided Software/System Engineering). Конечно, созданный таким образом интерфейсне является законченным программным продуктом, однако он позволяет заказчику оценить возможности конечного продукта и внести свои коррективы. Только после одобрения заказчиком рабочего прототипа разработчики приступают к ручному кодированию – созданию законченного приложения.
При сопровождении все повторяется, за тем исключением, что генерируется не все приложение целиком, а только часть, которую надо изменять.
На практике чаще всего CASE-средства используются для создания схемы базы данных в виде ER-диаграмм и генерации структур баз данных для конкретной СУБД. После получения от заказчика изменений разработчики вносят соответствующие исправления в диаграмму "сущность – связь" и заново генерируют структуры баз данных. Средства автоматической генерации интерфейсов используются реже.
В настоящее время практически каждый производитель СУБД предлагает собственный программный продукт автоматизированного проектирования. Это Oracle Designer (Oracle), Power Desinger (Sybase) и другие.
Кроме того, на рынке представлены решения третьих фирм, не производящих СУБД. Одними из самых распространенных являются программные продукты фирмы AllFusion – AllFusion ERwin Data Modeler и AllFusion Process Modeler (ранее – BPwin) и другие. Создание диаграммы "сущность –связь" осуществляется с помощью AllFusion ERwin Data Modeler, дальнейшее моделирование, включая генерацию программного кода создания базы данных производится с помощью программы AllFusion Process Modeler.
Создав наглядную модель базы данных можно оптимизировать структуру БД и добиться её полного соответствия требованиям и задачам организации. Визуальное моделирование повышает качество создаваемой базы данных, продуктивность и скорость её разработки.