Сколько нужно программистов чтобы написать программу

Некоторое время назад между мной и моим хорошим другом состоялся разговор, в котором прозвучали такие фразы:

— Количество программистов будет постоянно расти — ведь количество кода растет, и для его поддержки постоянно требуется все больше разработчиков.
— Но код стареет, часть его уходит из поддержки. Не исключено даже наличие какого-то равновесия.

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

Вопрос первый. Может ли поддержка «съесть» все ресурсы разработки?

Рассмотрим коллектив программистов, в котором число участников постоянно. Доля их рабочего времени () приходится на разработку нового кода, а оставшаяся доля времени уходит на поддержку. В рамках допущений модели предположим, что первый вид деятельности направлен на увеличение объёма кода, а второй — на его изменение (исправление ошибок) и существенного влияния на объём кода не оказывает.

Как в 44 года стать программистом на Python. Объясняю с чего начать.

Обозначим весь объём кода, написанный к моменту времени . Считая скорость написания кода пропорциональной , получаем:

Естественно предположить, что трудозатраты на поддержку кода пропорциональны его объёму:

Получаем дифференциальное уравнение, которое легко интегрируется. Если в начальный момент времени объем кода равен нулю, то

При функция , а . И это означает постепенное сокращение с течением времени разработки нового функционала до нуля и переход всех ресурсов на поддержку.

Однако, если за время код устаревает и перестаёт поддерживаться, то объём кода, требующего поддержки, в момент времени равен уже Тогда

а является решением дифференциального уравнения с запаздывающим аргументом [1]:

Решение такого уравнения однозначно определяется заданием значений «до начала времён», при . Так как до начального момента времени кода написано ещё не было, то в нашем случае при .

Рассмотрим несколько примеров. Будем измерять время в годах, а объём кода в тысячах строк. Тогда для приемлемыми являются значения порядка десятков, мы возьмём 50 и 100. То есть за год группа разработки напишет пятьдесят и сто тысяч строк кода соответственно.

Для приемлемыми могут быть величины: , , . Это означает, что группа разработчиков способна поддерживать объём кода, который написан ей же за год, при занятости на четверть, на половину или для этого требуется полная занятость. В качестве среднего времени жизни кода зададимся величинами: 1, 2 и 4 года. Решая уравнение численно, получим примеры поведения функции для некоторых комбинаций параметров .

Вся суть программирования за 15 минут…

Характер поведения функции в условиях старения кода изменился. Функция перестала быть монотонной, но колебания со временем «успокаиваются», наблюдается тенденция стремления к некоторому постоянному значению.

Графики показывают: чем больше , и , то есть чем медленнее стареет код, чем быстрее происходит разработка нового кода и чем ниже качество кода, тем меньше ресурсов будет оставаться для разработки нового функционала. Было желание привести хотя бы один пример, в котором «прижалась» близко к нулю. Но это потребовало подбора очень плохих показателей качества разработки и долго не стареющего кода. Даже на левом нижнем графике на новый функционал остается ощутимое количество ресурсов. Поэтому правильный ответ на первый вопрос скорее такой: теоретически — да, это возможно; практически — вряд ли.

Вопросы, на которые не удалось получить ответ:

1. Верно ли, что стремится к некоторому пределу при для всех ? Если не для всех, то для каких?
2. Если предел существует, то как его значение зависит от ?

Вопрос второй. Может ли поддержка кода стать причиной неограниченного роста количества программистов?

Обозначим количество программистов, занятых разработкой нового кода. Как и выше, — объём кода, написанного к моменту времени . Тогда

Пусть поддержкой кода заняты программистов. C учётом старения кода,

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

Заключение

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

Список литературы

1. Эльсгольц Л.Э., Норкин С.Б. Введение в теорию дифференциальных уравнений с отклоняющимся аргументом. Москва. Издательство «Наука». 1971.
2. Арнольд В.И. «Жесткие» и «мягкие» математические модели. Москва. Издательство МЦНМО. 2004.

• дифференциальные уравнения
• моделирование

• Математика
• Управление разработкой
• Исследования и прогнозы в IT

Источник: habr.com

Как определить количество программистов, необходимых для проекта

Как вы узнаете, сколько программистов для успеха конкретного проекта?

Компания, в которой я работаю, выполняет заказы для компаний-клиентов. Мы разработали собственную систему управления складом, которая занимается управлением запасами на основе местоположения, обработкой заказов, формированием накладных, выставлением счетов, аудитом грузов и отчетами (вероятно, 50 отчетов).

Он также имеет функции сканирования штрих-кода и клиентский портал, а также десятки других небольших функций. Он также включает в себя полное время сотрудника. Он интегрируется с Quickbooks, UPS и FedEx. Он обрабатывает работу как минимум для 50 клиентов, каждый из которых немного отличается по своей функциональности.

Например, мы импортируем заказы из файлов, которые отправляют клиенты, но каждый клиент отправляет свой формат файла (csv, excel, flat file и веб-сервисы), поэтому у нас есть более десятка настроек методов преобразования заказов. Экспорт это та же история.

Проект сложен и растет с каждым днем: более четверти миллиона строк кода. Это около 250 000 строк кода VB.NET, 6200 строк кода Ruby и, возможно, 5000 строк PHP. Он также имеет базу данных MySQL с около 200 таблицами.

Из-за постоянно меняющихся требований и различных потребностей десятков клиентов сам код значительно отличается по качеству от крайне плохого до относительно хорошего кода.

В настоящее время в этом проекте есть только один программист — я сам. Я также в настоящее время делаю всю поддержку продукта для нашей компании приблизительно 75 человек. Это включает устранение неполадок и настройку новых клиентов, а также любые новые необходимые функции. Кроме того, мы пытаемся переписать все это на 100% на основе Ruby on Rails. И мы хотели бы продать всю систему в течение следующего года или около того для использования другими компаниями.

В настоящее время у нас есть только я как программист, но я не считаю, что этого достаточно. Есть ли у кого-нибудь рекомендации относительно того, сколько программистов должен иметь проект такого масштаба или как мы должны определить ответ на этот вопрос? Особенно учитывая тот факт, что руководство хотело бы, чтобы продукт стал коммерческим качеством к следующему году?

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

Сколько 1С-программистов нужно, чтобы внедрить ERP на 10+ пользователей

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

1. Собирать консолидированную отчетность по компании — настоящее испытание. Может занимать неделю и больше.
2. Достоверность учета под вопросам. Данные могут разниться из-за разных информационных баз. Например, если сложно контролировать достоверность данных по остаткам материалов в производстве, может начаться бесконтрольное списание материалов.
3. Трудно аргументировать финансовую отчетность. Например, дебиторская задолженность не подкреплена первичным документами, а значит, в случае возникновения исковых требования предоставить нечего.

2. Какие разделы программного продукта нужно внедрить

1. Финансовый (управленческий) учет — для формирования достоверной финансовой отчетности, организации бюджетирования в компании с использованием встроенной подсистемы.
2. Оперативный учет — для получения достоверных данных в реальном времени. Например: остатки и резервы товаров, продукция клиента в производстве, какие материалы нужно закупить и когда.
3. Регламентированный учет — для формирования бухгалтерских отчетов. Использует данные финансового учета и правила их отражения в регламентированном учете.
4. Кадровый и зарплатный учеты — для расчета зарплаты, премий, налогов, взносов и кадровых перемещений.

3. Сколько же нужно программистов

1. Финансовый и регламентированный учет — один специалист.
2. Оперативный учет — один специалист. Если нужно внедрить пооперационное планирование, придется привлечь еще одного специалиста.
3. Кадровый и зарплатный учет — один специалист.
4. Создание дополнительных печатных форм, отчетов, написание методик и правил переноса данных из прежних программных продуктов, создание специализированный рабочих столов для сотрудников — один или два программиста.
5. Соблюдение технологии внедрения программы, ведение команд исполнителя и заказчика к результату, выполнение всех пунктов устава проекта — один менеджер.

Основная проблема с внедрением заключается в нехватке кадров. Ранее мы рассказывали, как правильно искать 1С-программиста . Если учесть требования к специфическим знаниям, то таких квалифицированных специалистов катастрофически мало.

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

Именно поэтому на внедрение ERP нужно несколько профильных, сертифицированных специалистов.

Источник: alt-soft.ru