Нормы на разработку программ

Основная работа инженера головой, чертеж оформление идеи

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

Для изготовления одного изделия минимум нужен: сборочный чертеж. чертеж детали, спецификация. Качественное КД — не нарисованные на бумаге линии, размеры, обозначения, а стремление быстро и эффективно получить исчерпывающее понимание конструкции спроектированного изделия, с минимальным но достаточным количеством размеров и требований для изготовления.

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

Например в одном институте проектном ввели нормы на чертежи: 8 А4 в день. Ни к чему хорошему это не привело. Можно начертить на А4, а можно то же самое на А2. Стали гнать листаж. Долго это не продержалось.

Паскина М.В. Основные методики разработки и применения сметных норм

Основная работа конструктора идет вообще не в чертежах. Чертеж — это всего лишь оформление готовой мысли.
Кстати, а почему не предлагают нормировать труд начальника количеством документов (или количеством страниц), которые он подписал? А на совещаниях он ничего не подписывает — выходит не работает на них? Совершенно аналогичная ситуация.

Расчет времени разработки КД.

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

Как объяснить, что физически не возможно выполнить заданный объем КД в отведенные сроки, человеку который далек от машиностроения, касаясь нормирования. Какая методика больше подходит для подсчета количества инженеров для выполнения какого-то размера заказа? Если заказ на 32400 трудочасов, а в пятидневке на восемь часов 162 часа в месяц получаем 200 инженеров необходимо для выполнения данного заказа в 1 месяц, но за 10 месяцев справятся 20 человек и так далее. но это все теория, на практике все как то по другому и не все так просто, или почему девять женщин, за один месяц не могут родить одного ребенка: конечно возможно если только одна из них на 8-м месяце беременности? Восьмом месяце.

Проектирование и ввод в эксплуатацию опытного образца котла Е-10-1,4ДР на котельной ОАО «ТБЗ Дитва»

Повторить в срок можно, заставить изобрести нельзя.

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

«Не продаётся вдохновенье, но можно рукопись продать!» А.С.Пушкин

Нормы и практика разработки адаптированной общеобразовательной программы

Даже 100 инженеров могут не справится если все не правильно организовано — 20 человек как то проще организовать (но зависит от изделия, может там нужна узкая специализация) и есть такое понятие как синергия умов, но относится это опять таки к правильной организации команды.

Для нормирования труда специалистов занятых конструкторской и технологической подготовкой производства, применяют «Типовые нормативы времени на разработку конструкторской документации. ШИФР 13.01.01» (утв. ФГБУ «НИИ ТСС» Минтруда России 07.03.2014 N 003). Этот документ является переработанным изданием «Типовых норм времени на разработку конструкторской документации» 2-е издание от 1991 года.

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

Нормы времени на конструкторскую документацию

Рассмотрим рекомендуемые нормы времени на выполнение единицы нормируемой работы разработка конструкторской документации на стадии «Рабочая конструкторская документация».

Источник: dzen.ru

Нормирование разработки программного обеспечения: обзор подходов

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

Не будем здесь рассматривать специально труд системных администраторов и специалистов технической поддержки. Тем более что на данную тему проведено много качественных исследований (см. например « Возможности для нормирования труда отдела ИТ »). Значительный (примерно 70%-80%) объем их работы – рутинные операции, поддающиеся регистрации, формализованному описанию и измерению.

Их трудоемкость проще всего рассчитать с использованием существующих норм (на постсоветском пространстве наиболее актуальными являются « Нормы времени на работы по обслуживанию персональных электронно-вычислительных машин, организационной техники и офисного оборудования », утвержденные Постановлением Министерства труда и социальной защиты Республики Беларусь от 23.03.2011 № 19). Отражённые в них операции можно уточнить / подтвердить, а отсутствующие — выявить дополнительными исследованиями затрат времени прямо «на местах» (фотография рабочего времени (ФРВ), хронометражные замеры и т.д.). Этими же методами можно определить также примерный объем нетипичных задач, как и фактический баланс рабочего времени работников в целом.

Разработчики ПО – дело другое. Их работа более разнообразна и зависима от большего числа факторов. Но и здесь есть серьезные заделы в части нормирования труда, среди которых можно отдельно выделить[1]:

– модели COCОMO и COCOMO—II (метод расчета трудозатрат на основе количества строк кода), которые целесообразно применять при наличии сложных проектов разработки;

– Укрупненные нормы затрат труда на разработку программного обеспечения (далее — Укрупненные нормы) – опять же результат основательных работ, проведенных в Белоруссии (Постановление Министерства труда и социальной защиты Республики Беларусь от 27.06.2007 № 91. Об утверждении укрупненных норм затрат труда на разработку программного обеспечения.

В этих документах все основательно проработано, а на основе Укрупненных норм при разумных трудозатратах вполне можно сделать калькулятор трудоемкости разработки ПО с разбивкой по стадиям согласно ГОСТам Единой системы программной документации:

• техническое задание;
• эскизный проект;
• технический проект;
• рабочий проект;
• ввод в действие.

Подробный разбор модели COCOMO II приведен здесь , Укрупненных норм — здесь .

Однако применение и COCОMO, и Укрупненных норм требует не только глубокой погруженности нормировщика в процесс разработки ПО и в особенности языков программирования, но и существенных трудозатрат на анализ ПО методом функциональных точек. Кроме того, эти подходы применимы только для случаев разработки нового ПО и проведения доработок. Их «слепые зоны» – внедрение коробочного решения и устранение дефектов ПО. Конечно, для заполнения этих пробелов можно использовать и экспертный метод определения норм труда. Но зачастую это неоправданно затрудняет нормирование, да и оспорить результаты таких работ — намного проще из-за субъективности оценок трудозатрат.

В ряде случаев выходом может стать нормирование труда на основе статистики JIRA или другой аналогичной Системы отслеживания ошибок (Продолжение следует) .

[1] Включая, но не ограничиваясь

Источник: orgdevelopment.ru

Глава 2 Расчет трудоемкости разработки программного продукта

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

• Использование CASE-технологий;
• Объединение технического и рабочего проекта.

CASE (Continuous Acquisitionand LifecycleSupport) — непрерывная информационная поддержка жизненного цикла продукта.

При использовании CASE-технологии стадии «Техническое задание», «Эскизный проект» и «Технический проект» объединяются в одну стадию «Предварительное проектирование», за которой следуют стадии «Рабочий проект» и «Внедрение» [10].

Объединение стадий «Технический проект» и «Рабочий проект» в одну стадию «Технорабочий проект «, предполагает обязательные работы по этим стадиям.

Существуют два вида ТЗ, в зависимости от источника (инициатора):

• ТЗ регламентировано заказчиком. В этом случае, как правило, разработчику указывается срок окончания работы по созданию ПП;
• ТЗ формируется самим разработчиком. В этом случае самим разработчиком устанавливается срок начала работ.

Общая трудоемкость и длительность создания конкретного ПП рассчитывается на основе выбранного алгоритма разработки (табл.2).

Виды алгоритмов разработки ПП. Расчет трудоемкости разработки программного продукта

Разработка ПП разбивается на следующие этапы [1]:

Выбрав алгоритм разработки ПП (например, 1а или 2в) в зависимости от конкретных данных условий проектирования, необходимо переходить к расчету трудоемкости разработки.

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

По степени новизны разрабатываемая ПП может быть отнесена к одной из четырех групп:

1. Группа новизны «А» — разработка программных комплексов, требующих использования принципиально новых методов их создания, проведение НИР и т.п.
2. Группа новизны «Б» — разработка программной продукции, не имеющей аналогов, в том числе разработка пакетов прикладных программ.
3. Группа новизны «В» — разработка программной продукции, имеющей аналоги.
4. Группа новизны «Г» — разработка программной продукции, основанная на привязке типовых проектных решений.

По степени сложности алгоритма функционирования программная продукция может быть отнесена к одной из трех групп:

первая группа сложности — программная продукция, реализующая оптимизационные и моделирующие алгоритмы;

вторая группа сложности — программная продукция, реализующая учетно-статистические алгоритмы;

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

Трудоёмкость разработки программной продукции Тпп может быть определена как сумма величин трудоёмкости выполнения отдельных стадий разработки ПП из выражения[5]:

Тпп = Ттз+ + Тэп + Ттп + Трп + Тв (5) (5),

где: Ттз — трудоёмкость разработки технического задания на создание ПП, тэп — трудоёмкость разработки эскизного проекта, Ттп — трудоёмкость разработки технического проекта ПП, трп — трудоёмкость разработки рабочего проекта ПП, тв — трудоёмкость внедрения разработанного ПП. Трудоёмкость разработки технического задания на создание ПП рассчитывается по формуле[6]:

Ттз = Трпз + Трпо (6) (6),

где: Трпз- затраты времени разработчика постановки задач на разработку ТЗ, чел.-дни; Трпо- затраты времени разработчика программного обеспечения на разработку ТЗ, чел.-дни. Значения величин Трпз и Трпо рассчитываются по формулам[7,8]:

Трпз = tр • Кзрз (7) (7),

Трпо = tр • Кзрп (8) (8),

где: tр — норма времени на разработку ТЗ на программный продукт в зависимости от функционального назначения и степени новизны разрабатываемого ПП, чел.-дни (приложение 1 табл. 2);

Кзрз- коэффициент, учитывающий удельный вес трудоёмкости работ, выполняемых разработчиком постановки задач на стадии ТЗ (в случае совместной с разработчиком ПП разработки ТЗКзрз = 0,35); Кзрп — коэффициент, учитывающий удельный вес трудоёмкости работ, выполняемых разработчиком ПП на стадии ТЗ (в случае совместной с разработчиком постановки задач Кзрп= 0,65).

Трудоёмкость разработки эскизного проекта ПП тэп рассчитывают по формуле[9]:

Тэп = Тэрз+ Тэрп (9) (9),

где ТэРЗ — затраты времени разработчика постановки задач на разработку ЭП, чел.-дни; ТэРП — затраты времени разработчика ПП на разработку ЭП, чел.-дни.

Значения величин Тэрз и Тэрп рассчитываются по формулам[10,11]:

Тэрз = tэп • Кэрз (10) (10),

Тэрп = tэп • Кэрп (11) (11),

где: tэп — норма времени на разработку ЭП на программный продукт в зависимости от функционального назначения и степени новизны разрабатываемого ПП, чел.-дни (приложение 1 табл. 3); Кэрз — коэффициент, учитывающий удельный вес трудоёмкости работ, выполняемых разработчиком постановки задач на стадии ЭП (0,35); Кэрп — коэффициент, учитывающий удельный вес трудоёмкости работ, выполняемых разработчиком ПП на стадии ЭП (0,65).

Трудоёмкость разработки технического проекта Ттп зависит от функционального назначения ПП, количества разновидностей форм входной и выходной информации и определяется как сумма времени, затраченного разработчиком постановки задач и разработчиком ПП[12]:

Ттп=(tTрз+ + Тгрп) • (Кв-Кр) (12)

где: tTP3 , tTPn — норма времени, затрачиваемого на разработку ТП разработчиком постановки задач и разработчиком ПП соответственно, чел.-дни (приложение 1 табл.4-16); Кв — коэффициент учёта вида используемой информации; Кр — коэффициент учёта режима обработки информации (при разработке ТП Кр = 1,10 (приложение 1 табл.17)).

Значение коэффициента Кв определяют из выражения[13]:

Кв = (Кп • Пи + Кнс • Пнс + Кб • Пб) / (Пи + Пнс + Пб ) (13)

где: Кп, Кнс, Кб — значения коэффициентов учёта вида используемой информации для переменной, нормативно-справочной информации и баз данных соответственно (приложение 1 табл.18); Пи, Пнс, Пб — количество наборов данных переменной, нормативно-справочной информации и баз данных соответственно (Пи = 6, Пнс = 4, Пб = 0).

Трудоёмкость разработки технического проекта Трп зависит от функционального назначения ПП, количества разновидностей форм входной и выходной информации, сложности алгоритма функционирования, сложности контроля информации, степени использования готовых программных модулей, уровня алгоритмического языка программирования и определяется по формуле[14]:

Трп = Тпп+ + Тпп •( Кк-Кр- Кя) • Киа (14) (14),

где: Кк — коэффициент учёта сложности контроля информации (приложение 1 табл.19); Кр — коэффициент учёта режима обработки информации (приложение 1 табл.17); Кя — коэффициент учёта уровня алгоритмического языка программирования (приложение 1 табл.20); Кз — коэффициент учёта степени использования готовых программных модулей (приложение 1 табл.21); Киа — коэффициент учёта вида используемой информации и сложности алгоритма ПП.

Значение коэффициента Киа определяют из выражения[15]:

Кв = (К’п • Пи + К’нс • Пнс + К’б • Пб) / (Пи + Пнс + Пб ) (15)

где: К’п, К’нс, К’б — значения коэффициентов учёта сложности алгоритма ПП и вида используемой информации для переменной, нормативно-справочной информации и баз данных соответственно (приложение 1 табл.22); tpp3,tppn — нормы времени, затрачиваемые на разработку РП на алгоритмическом языке высокого уровня разработчиком постановки задач и разработчиком ПП соответственно, чел.-дни (приложение 1 табл.23-35).

В данном случае при разработке ПП стадии «Технический проект» и «Рабочий проект» объединяются в стадию «Технорабочий проект» и трудоёмкость её выполнения Ттрп определяется по формуле[16]:

Ттрп = 0,85ттп + трп (16)

Трудоёмкость выполнения стадии «Внедрение» может быть рассчитана по формуле[17]:

Тв = tBP + tBP •( Кк-Кр- Кя) (17)

где tвpз, tвpп — норма времени, затрачиваемого разработчиком постановки задач и разработчиком ПП соответственно на выполнение процедур внедрения ПП, чел.-дни (приложение 1 табл.36-48).

Продолжительность выполнения всех работ по этапам разработки ПП определяют из формулы[18]:

Ti = (Pi + Q) / Hi (18) (18)

Ti — трудоёмкость Рi-ой работы, чел.-дни; Q — трудоёмкость дополнительных работ, выполняемых исполнителем, чел.-дни; Нi- количество исполнителей, выполняющих i-ую работу, чел.

Источник: studfile.net