Производительность программирования (также называемая производительностью программного обеспечения или производительностью разработки ) описывает степень способности отдельных программистов или групп разработчиков создавать и развивать программные системы. Производительность традиционно определяется соотношением количества произведенного программного обеспечения и затрат, затраченных на него. Здесь деликатность заключается в поиске разумного способа определения количества программного обеспечения.
Производительность — важная тема, изучаемая в таких различных дисциплинах, как производство, организационная психология, промышленный инжиниринг, стратегический менеджмент, финансы, бухгалтерский учет, маркетинг и экономика. Уровни анализа включают индивидуальный, групповой, дивизиональный, организационный и национальный уровни. [1] Из-за такого разнообразия не существует четкого определения производительности и факторов, влияющих на нее, хотя исследования проводятся уже более века. Как и в разработке программного обеспечения, отсутствие общего согласия относительно того, что на самом деле представляет собой производительность, воспринимается как серьезное препятствие для обоснованного обсуждения производительности. [2] Следующие определения описывают наилучший консенсус в отношении терминологии. [3]
Хотя не существует общепринятого определения производительности, похоже, существует согласие в том, что производительность описывает соотношение между выпуском и затратами:
Производительность = Выход/Вход
Однако в различных дисциплинах можно встретить разные понятия и, в частности, разные единицы измерения входных и выходных данных. В обрабатывающей промышленности обычно используется прямая зависимость между количеством произведенных единиц и количеством потребляемых единиц. [4] В непроизводственных отраслях обычно используются человеко-часы или аналогичные единицы, чтобы обеспечить сравнение результатов и ресурсов.
Одно из основных соглашений заключается в том, что значение производительности и средства ее измерения различаются в зависимости от того, какой контекст оценивается. В производственной компании возможные контексты: [3]
Пока рассматриваются классические производственные процессы, прямой показатель производительности прост: сколько единиц продукта заданного качества производится с какими затратами. Что касается интеллектуальной работы, то с продуктивностью дело обстоит гораздо сложнее. Как мы измеряем продуктивность авторов, ученых или инженеров? В связи с растущей важностью интеллектуального труда (в отличие от ручного труда) [5] многие исследователи пытались разработать средства измерения производительности, которые можно было бы применять в непроизводственном контексте. Принято считать, что характер работы, связанной с знаниями, фундаментально отличается от ручного труда, и, следовательно, необходимо учитывать факторы, помимо простого соотношения результатов и затрат, например, качество, своевременность, автономность, успех проекта, удовлетворенность клиентов и инновации. Однако исследовательские сообщества ни в одной из дисциплин пока не смогли разработать широко применимые и признанные средства измерения производительности. [1] То же самое справедливо и для более конкретной области продуктивности программирования.
Рентабельность и производительность тесно связаны между собой, и их фактически часто путают. Однако, поскольку рентабельность обычно определяется как соотношение выручки и себестоимости
Рентабельность = Выручка/Затраты
Он имеет более широкий охват, чем производительность, т.е. количество факторов, влияющих на прибыльность, больше, чем количество факторов, влияющих на производительность. В частности, рентабельность может меняться без каких-либо изменений производительности, например, из-за внешних условий, таких как инфляция издержек или цен. Кроме того, взаимозависимость между производительностью и прибыльностью обычно проявляется с задержкой, т.е. рост производительности редко отражается на немедленном росте прибыльности, который, скорее всего, реализуется в долгосрочной перспективе.
Термин «производительность» даже шире, чем производительность и прибыльность, и охватывает множество факторов, влияющих на успех компании. Следовательно, хорошо известные инструменты контроля производительности, такие как сбалансированная система показателей , действительно включают производительность в качестве центрального, но не уникального фактора. Другими важными факторами являются, например, восприятие компании клиентами или заинтересованными сторонами.
Эффективность и результативность — это термины, которые приводят к еще большей путанице, поскольку их сами часто путают, и, кроме того, эффективность часто путают с производительностью. Разницу между эффективностью и результативностью обычно объясняют неформально: эффективность – это правильные действия , а эффективность – правильные действия . Хотя существует множество других определений, [3] существует определенное согласие в том, что эффективность относится к использованию ресурсов и в основном влияет на требуемый коэффициент производительности. С другой стороны, эффективность в основном влияет на коэффициент производительности, поскольку обычно имеет прямые последствия для клиента. Эффективность можно определить как «способность достичь желаемого результата».
Обычно предполагается, что эффективность можно определить количественно, например, по коэффициентам использования, что значительно легче, чем эффективность.
Танген утверждает: «Улучшение качества, за исключением того факта, что бездефектная продукция увеличивает объем выпуска, не должно включаться в концепцию производительности». [3] Однако в большей части классической литературы по дисциплинам, не связанным с программным обеспечением, особенно в производственной сфере, прямо не обсуждается роль качества продукции в коэффициенте производительности. [6] В более поздних работах из непроизводственных дисциплин больше внимания уделяется знаниям, офисной работе или работе «белых воротничков» и, следовательно, все чаще обсуждается роль качества по отношению к качеству. [5] [1] [7] [8] [9]
Друкер подчеркивает важность качества для оценки производительности работников умственного труда: «Поэтому производительность умственной работы должна быть направлена в первую очередь на достижение качества – и не минимального качества, а оптимального, если не максимального качества. Только тогда можно задаться вопросом: «Каков объем , количество работы?"" [5]
Саари подчеркивает важность качества в своей расширенной формуле производительности: [8]
Общая производительность = (качество и количество вывода)/(качество и количество ввода)
Однако, похоже, что эти попытки включить качество в определение производительности еще не привели к практической реализации концепции. В настоящее время остается неясным, как количественно оценить расплывчатые понятия «качество и количество выпускаемой продукции», а также «качество и количество вводимых ресурсов», не говоря уже о расчете соотношения.
В разработке программного обеспечения дела обстоят сложнее, чем в производстве товаров. Разработка программного обеспечения — это инженерный процесс.
Бём был одним из первых исследователей, которые систематически подошли к проблеме производительности программного обеспечения. Его модель оценки затрат COCOMO – теперь COCOMO II [10] – представляет собой стандартные знания в области разработки программного обеспечения. В этой модели он определяет набор факторов, влияющих на производительность, таких как требуемая надежность или возможности аналитиков. Эти факторы широко использовались в других аналогичных подходах к повышению производительности. Остальная часть модели основана на функциональных точках и, наконец, строках исходного кода (LOC). Ограничения LOC как показателя производительности хорошо известны.
Джонс — автор серии книг по продуктивности программного обеспечения. Помимо нескольких теоретических соображений, его основным вкладом является систематическое предоставление и интеграция большого количества данных, необходимых для анализа производительности. По крайней мере, в двух своих книгах, [11] [12] он приводит ряд факторов производительности, но также указывает, что для каждого проекта влияет свой набор факторов. Эти факторы могут служить основой для оценки производительности и сравнения со средними показателями по отрасли.
Вот один из таких списков:
Вот 20 факторов, количественное влияние которых на программные проекты было определено на основе исторических данных:
- Используемый язык программирования
- Размер программы
- Опыт программистов и дизайнерского персонала
- Новизна требований
- Сложность программы и ее данных
- Использование методов структурного программирования
- Класс программы или метод распространения
- Тип программы области применения
- Инструменты и условия окружающей среды
- Улучшение существующих программ или систем
- Поддержание существующих программ или систем
- Повторное использование существующих модулей и стандартных проектов
- Генераторы программ
- Языки четвертого поколения
- Географическое разделение мест разработки
- Возможные дефекты и методы устранения
- Существующая документация
- Прототипирование до начала основной разработки
- Проектные команды и организационные структуры
- Моральный дух и оплата труда персонала [12]
Функциональные точки были предложены Альбрехтом в 1977 году как лучшая мера размера программного обеспечения, чем LOC. В том, что он основан на спецификации программного обеспечения и, таким образом, направлен на измерение размера его функциональности, а не самого кода. Причина в том, что размер кода зависит не только от размера функциональности, но и от способностей программиста: лучшие программисты будут создавать меньше кода для той же функциональности. За прошедшие годы функциональные точки претерпели несколько изменений, в основном по инициативе Международной группы пользователей функциональных точек (IFPUG). Эта группа большая, в нее входят более 1200 компаний, что свидетельствует о довольно активном принятии этой меры. Однако во многих областях ему все еще не хватает практического применения, поскольку часто считается, что он применим только к информационным системам бизнеса.
Некоторые исследователи предложили разработку программного обеспечения, ориентированную на экономику или ценность, в качестве важной парадигмы в будущих исследованиях в области разработки программного обеспечения. Бём и Хуанг отмечают, что важно отслеживать не только затраты на программный проект, но и реальную заработанную стоимость, то есть ценность для клиента. [13] Они объясняют, что важно создать экономическое обоснование программного обеспечения и поддерживать его в актуальном состоянии. По сути, разработка программного обеспечения, основанная на стоимости, фокусируется на потребительской ценности, измеряемой главным образом в денежных единицах.
Знаменитая книга Де Марко и Листера «Людское обеспечение: продуктивные проекты и команды» [14] привлекла внимание более широкой аудитории к важности факторов, связанных с людьми. Во многих проектах по разработке программного обеспечения они собрали опыт хороших и плохих управленческих практик, влияющих на продуктивность команды. Они и другие показали, что это решающие проблемы в разработке программного обеспечения, но смогли описать их лишь эпизодически.
Вероятно, существует большое количество факторов, влияющих на продуктивность программирования отдельных лиц и команд. Например, используемый процесс разработки программного обеспечения , вероятно, влияет на эффективность и результативность команды.
Личности программистов влияют на используемые стили кодирования , которые, в свою очередь, влияют на производительность программистов. [15]
В 2007 году комикс xkcd популяризировал концепцию пика Баллмера — что программист, приняв достаточное количество опьянения , достигает высокого уровня производительности. Пик Балмера назван в честь бывшего генерального директора Microsoft Стива Балмера [ 16] и, вероятно, представляет собой игру на серии спектральных линий водорода Бальмера , названных в честь Иоганна Балмера . [17]