Совершенствование системы нормирования труда инженеров-программистов на примере "КБТЭМ-ОМО"...
Курсовой проект - Разное
Другие курсовые по предмету Разное
Как отмечалось выше, подразделением, которое занимается нормированием труда в КБТЭМ-ОМО, является группа из двух экономистов в составе планово-экономического отдела. Однако должности нормировщиков-экономистов в ПЭО КБТЭМ-ОМО вакантны. Таким образом, нормирование инженерного труда в КБТЭМ-ОМО в настоящее время отсутствует.
Одним из путей улучшения работы предприятия в части снижения издержек производства, повышения прибыли и рентабельности может быть внедрение нормирования труда инженеров-конструкторов и инженеров-программистов, как основных работников рассматриваемого конструкторского бюро.
Проведённый анализ современного состояния организации и нормирования труда на промышленных предприятиях и в КБТЭМ-ОМО в частности показал, что
- предприятия в условиях предоставленной им самостоятельности резко снизили уровень работы по повышению прогрессивности норм труда. На предприятиях отраслей промышленности удельный вес пересмотренных норм и эффективность этой работы в 2006 году уменьшились по сравнению с 2005 году от 7 до 12 раз. Повсеместно на предприятиях действуют слабые ненапряжённые нормы затрат труда.
- Прекратилось обеспечение предприятий республики нормативно-методическими материалами по организации и нормированию труда, а ранее разработанные межотраслевые и отраслевые сборники уже устарели и не соответствуют сложившимся организационно-техническим условиям производства. Так, на работы, выполняемые руководителями, специалистами и служащими, требуют переработки и корректировки 9 (47%) межотраслевых сборников.
Всё вышесказанное в полной мере относится к КБТЭМ-ОМО и концерну Планар в целом.
2.4. Нормирование труда инженера-проектировщика
Нормирование труда в процессе создания программного изделия связано с теми же трудностями, что и нормирование другого вида труда, содержащего как чисто технические (рутинные), так и творческие элементы. Творческие элементы труда программистов практически не нормируются, они могут либо определяться на основе экспертных оценок опытных программистов, либо жёстко задаваться сроками разработки, за которые программист обязан найти решение. Технические элементы труда программистов достаточно хорошо поддаются нормированию, но точность таких норм имеет большой разброс в зависимости от целого ряда факторов. Известно много подходов к оценке трудоёмкости создания программного изделия. Все они, как правило, базируются на определённых зависимостях трудоёмкости программного изделия от его основных параметров, и в первую очередь от числа исходных или машинных команд.
В частности, уравнения базовой модели для оценки трудоёмкости и продолжительности разработки программного изделия в [10] предлагается представлять в следующем виде (табл.2.5.)
Таблица 2.5.
Уравнения базовой модели для оценки трудоёмкости и продолжительности разработки программного изделия
Тип программного изделияТрудоёмкость разработки, чел/мес tПродолжительность разработки, TНезависимыйПолунезависимыйВстроенный
Примечание: nтик число тысяч исходных команд в тексте программы.
На наш взгляд определение трудоёмкости программной разработки по табл.1.2. имеет следующие недостатки:
Недостаток 1. Таблица привязана к числу тысяч исходных команд в тексте программы. Таким образом получается, что неопытный программист напишет одну и ту же программу по сравнению с опытным с числом nтик предположим в 1,5 раза больше, чем у опытного программиста, т.е. у неопытного nтик = 15000 команд, а у опытного 10000. Тогда, для встроенного типа программного изделия трудоёмкость разработки для неопытного программиста равна
= = 67,0 чел/мес, (1.7)
а для опытного программиста
= =41,2 чел/мес(1.8)
Следовательно, в табл.1.2 необходимо вносить коррективы, учитывающие опыт программистов. В противном случаи нормирование трудоёмкости разработки программы по табл.1.2. приводит к тому, что будет поощряться так называемая корявая разработка программ, когда вместо того, чтобы подумать как написать какое-либо действие одной команды программист пишет две команды. Выше описанная корявая разработка приводит к дополнительным затратам времени на тестирование программы, поэтому неясно, будет ли выигрыш при нормировании, либо проигрыш при тестировании.
Недостаток 2. Вызывает сомнения, что для типа программного изделия независимый по сравнению с типом программного изделия встроенный трудоёмкость разработки программы величиной 10000 исходных команд должна уменьшиться в 41,2/26,9=1,5 раза. Действительно, для типа встроенный, названная трудоёмкость должна равняться
= =26,9 чел/мес(1.9)
Получается, что если программист разрабатывает программу, встраиваемую в какой-либо разрабатываемый программный комплекс, то на разработку такого модуля ему необходимо выделить в 1,5 раза больше времени, чем на разработку независимой или автономной программы. На наш взгляд это ничем логически не подтверждается программисту всё - равно, будет его программа встраиваться в комплекс или не будет. Просто для встраиваемой программы в техническом задании на разработку необходимо указать требования к встраиваемости. Таким образом, вследствие отмеченных недостатков, предлагаемая в {10} методология нормирования труда программистов не может быть рекомендована к практическому использованию. Методология может применяться только как начало проведения дальн?/p>