Производительность программирования - Programming productivity

Производительность программирования (также называется производительность программного обеспечения или продуктивность разработки) описывает степень способности отдельных программистов или групп разработчиков создавать и развивать программные системы. Под производительностью традиционно понимается соотношение между количеством произведенного программного обеспечения и затраченными на него затратами. Здесь тонкость заключается в поиске разумного способа определения количества программного обеспечения.

Терминология

Производительность - важная тема, исследуемая в таких различных дисциплинах, как производство, организационная психология, промышленная инженерия, стратегическое управление, финансы, бухгалтерский учет, маркетинг и экономика. Уровни анализа включают индивидуальный, групповой, дивизиональный, организационный и национальный уровни [5]. Из-за такого разнообразия нет четкого определения продуктивности и факторов, на которые она влияет, хотя исследования проводились уже более века. Как и в разработке программного обеспечения, отсутствие единого мнения о том, что на самом деле составляет производительность, воспринимается как главное препятствие для обоснованного обсуждения производительности.[1] Следующие определения описывают лучший консенсус по терминологии.[2]

Продуктивность

Хотя не существует общепринятого определения производительности, похоже, есть согласие, что производительность описывает соотношение между выпуском и затратами:

Производительность = Выход / Вход

Однако в разных дисциплинах можно найти разные понятия и, в частности, разные единицы измерения для ввода и вывода. В обрабатывающей промышленности обычно используется прямая зависимость между количеством произведенных единиц и количеством потребленных единиц.[3] Непроизводственные отрасли обычно используют человеко-часы или аналогичные единицы для сравнения результатов и затрат.

Одно из основных соглашений заключается в том, что значение производительности и способы ее измерения меняются в зависимости от того, какой контекст оценивается. В производственной компании возможны следующие ситуации:[2]

  • отдельная машина или производственная система;
  • производственная функция, например сборка;
  • процесс производства отдельного продукта или группы связанных продуктов;
  • фабрика; и
  • вся заводская система компании

Пока классические производственные процессы считаются прямым показателем производительности, прост: сколько единиц продукта заданного качества произведено по каким затратам. Для интеллектуальной работы производительность намного сложнее. Как мы измеряем продуктивность авторов, ученых или инженеров? Из-за растущего значения умение работать (в отличие от ручной работы),[4] многие исследователи пытались разработать средства измерения производительности, которые можно было бы применять в непроизводственном контексте. Принято считать, что природа умственной работы в корне отличается от ручной работы, и, следовательно, необходимо принимать во внимание факторы помимо простого соотношения выход / вход, например качество, своевременность, автономность, успех проекта, удовлетворенность клиентов и инновации. Однако исследовательские сообщества ни в одной из дисциплин пока не смогли разработать широко применимые и общепринятые средства измерения производительности.[5] То же самое и в более конкретной области продуктивного программирования.

Рентабельность

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

Прибыльность = Доход / Стоимость

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

Спектакль

Термин «производительность» шире, чем «производительность» и «рентабельность», и охватывает множество факторов, влияющих на успех компании. Следовательно, хорошо известные инструменты контроля производительности, такие как Сбалансированная система показателей действительно включают производительность как фактор, который является центральным, но не уникальным. К другим важным факторам относятся, например, восприятие компании клиентами или заинтересованными сторонами.

Эффективность и действенность

Эффективность и результативность - это термины, которые еще больше сбивают с толку, поскольку сами по себе часто путают, и, кроме того, эффективность часто путают с производительностью. Разницу между эффективностью и действенностью обычно неформально объясняют следующим образом: эффективность делает все правильно и эффективность делает правильные вещи. Хотя существует множество других определений,[2] Существует определенное согласие с тем, что эффективность относится к использованию ресурсов и в основном влияет на требуемый вклад коэффициента производительности. С другой стороны, эффективность в основном влияет на результат коэффициента производительности, так как обычно имеет прямые последствия для клиента. Эффективность можно определить как «способность достичь желаемого результата».

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

Качественный

Танген заявляет: «Улучшения качества, кроме того факта, что безупречная продукция увеличивает уровень выпуска, не должны включаться в концепцию производительности».[2] Однако в большей части классической литературы по непрограммным дисциплинам, особенно в области производства, прямо не обсуждается роль качества продукции в коэффициенте производительности.[6] В более поздних работах из непроизводственных дисциплин больше внимания уделяется знаниям, офисной работе или работе белых воротничков, и поэтому все чаще обсуждается роль качества по отношению к качеству.[4][5][7][8][9]

Друкер подчеркивает важность качества для оценки производительности работников умственного труда: «Поэтому продуктивность умственной работы должна быть направлена ​​в первую очередь на достижение качества - и не минимального, а оптимального, если не максимального качества. Только тогда можно спросить:« Каков объем , количество работы? ""[4]

Саари подчеркивает важность качества своей расширенной формулой производительности:[8]

Общая производительность = (Качество и количество выпускаемой продукции) / (Качество и количество на входе)

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

Последние достижения в области программирования

В разработке программного обеспечения дела обстоят сложнее, чем в производстве товаров. Разработка программного обеспечения - это инженерный процесс.

КОКОМО II

Бем был одним из первых исследователей, которые систематически подошли к области производительности программного обеспечения. Его модель оценки затрат КОКОМО - теперь COCOMO II[10] - стандартные знания в области программной инженерии. В этой модели он определяет набор факторов, влияющих на производительность, таких как требуемая надежность или возможности аналитиков. Эти факторы широко используются в других аналогичных подходах к повышению производительности. Остальная часть модели основана на функциональных точках и, наконец, исходные строки кода (LOC). Ограничения LOC как показателя производительности хорошо известны.

Производительность программного обеспечения Джонса

Джонс - автор серии книг по производительности программного обеспечения. Помимо нескольких теоретических соображений, его главный вклад - это систематическое предоставление и интеграция большого количества данных, необходимых для анализа производительности. По крайней мере, в двух его книгах[11][12] он приводит ряд факторов производительности, но также указывает, что для каждого проекта влияет различный набор факторов. Эти факторы могут лечь в основу оценок производительности и сравнения со средними отраслевыми показателями.

Это один из таких списков:

Вот 20 факторов, количественное влияние которых на программные проекты было определено на основе исторических данных:

  • Используемый язык программирования
  • Размер программы
  • Опыт программистов и дизайнерского персонала
  • Новизна требований
  • Сложность программы и ее данных
  • Использование методов структурного программирования
  • Класс программы или метод распространения
  • Тип программы области приложения
  • Инструменты и условия окружающей среды
  • Улучшение существующих программ или систем
  • Обслуживание существующих программ или систем
  • Повторное использование существующих модулей и стандартных конструкций
  • Генераторы программ
  • Языки четвертого поколения
  • Географическое разделение мест разработки
  • Возможности дефекта и методы устранения
  • (Существующая) документация
  • Создание прототипа до начала основной разработки
  • Проектные команды и организационные структуры
  • Моральный дух и оплата труда персонала[12]

Функциональные точки

Функциональные точки были предложены в 1977 году Альбрехтом как лучшая мера размера программного обеспечения, чем LOC. В этом смысле он основан на спецификации программного обеспечения и, таким образом, направлен на измерение размера его функциональности, а не самого кода. Причина в том, что размер кода зависит не только от размера функциональности, но и от возможностей программиста: лучшие программисты будут производить меньше кода для тех же функций. Функциональные точки претерпели несколько модификаций за эти годы, в основном под влиянием Международной группы пользователей функциональных точек (IFPUG). Это большая группа, в которую входят более 1200 компаний, что свидетельствует о довольно сильном принятии этой меры. Однако во многих областях ему по-прежнему не хватает практического применения, поскольку часто считается, что он применим только к системам деловой информации.

Разработка программного обеспечения на основе ценности

Несколько исследователей предложили ориентированную на экономику или ценность программную инженерию в качестве важной парадигмы в будущих исследованиях программной инженерии. Бём и Хуанг отмечают, что важно отслеживать не только затраты на программный проект, но и реальную освоенную стоимость, то есть ценность для клиента.[13] Они объясняют, что важно создать бизнес-обоснование программного обеспечения и поддерживать его в актуальном состоянии. По сути, разработка программного обеспечения на основе ценности фокусируется на ценности для потребителя, в основном измеряемой в денежных единицах.

Peopleware

Знаменитая книга Peopleware: продуктивные проекты и команды де Марко и Листер[14] довели важность факторов, связанных с людьми, до внимания более широкой аудитории. Во многих проектах по разработке программного обеспечения они накопили опыт хорошей и плохой практики управления, которая влияет на продуктивность команды. Они и другие показали, что это решающие проблемы в разработке программного обеспечения, но смогли описать их только анекдотично.

Факторы, влияющие на продуктивность программирования

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

В личности программистов влияют на используемые стили кодирования, которые, в свою очередь, влияют на производительность программистов.[15]

использованная литература

  1. ^ Нил, А., Хескет, Б., Андерсон, Н., Онес, Д. С., Синангил, Х. К., Висвесваран, К. (ред.) Справочник по продуктивности производственной, трудовой и организационной психологии в организациях. Sage Publications Ltd, 2002, стр. 8-24
  2. ^ а б c d Танген, С. Демистификация производительности и производительности, Международный журнал производительности и производительности, 2005, 54, 34-36
  3. ^ Чу, Б. В. Серьезное руководство по измерению производительности. Harvard Business Review, 1988, 66, 110-115
  4. ^ а б c Друкер, П. Ф. Производительность работников умственного труда: самая большая проблема. California Management Review, 1999, 41, 79-94
  5. ^ а б Рамирес, Ю. В., Нембхард, Д. А. Измерение производительности работников умственного труда: таксономия. Журнал интеллектуального капитала, 2004, 5, 602-628
  6. ^ Томас Б. Э. и Барон Дж. П. Оценка производительности интеллектуальных работников: обзор литературы, Исследовательская лаборатория строительной инженерии (USACERL), 1994
  7. ^ Аль-Дарраб, И. А. Взаимосвязь между производительностью, эффективностью, использованием и качеством. Рабочий кабинет, 2000, 49, 97-104
  8. ^ а б Саари, С. Производительность: теория и измерение. В Business Proc. Европейской конференции по производительности (EPC), 2006 г.
  9. ^ Рэй, П., Саху, С. Измерение и оценка производительности белых воротничков. Международный журнал операций и управления производством, 1989, 9, 28-47
  10. ^ Boehm et al. Оценка стоимости программного обеспечения с COCOMO II, 2000
  11. ^ Джонс, Каспер (2000). Оценка программного обеспечения, тесты и передовые методы. Бостон, Массачусетс: Аддисон-Уэсли.
  12. ^ а б Джонс, Каспер (1986). Производительность программирования. Нью-Йорк: Книжная компания Макгроу-Хилл. п.85 –86. ISBN  9780070328112. OCLC  611260287. Получено 14 апреля 2020.
  13. ^ Барри Бём, Ли Го Хуан. Разработка программного обеспечения на основе ценности: пример из практики. Программное обеспечение IEEE, 2003 г.
  14. ^ Том ДеМарко, Тимоти Листер. Peopleware: продуктивные проекты и команды, 1987
  15. ^ Карими, Захра; Бараани-Дастджерди, Ахмад; Гасем-Агаи, Насер; Вагнер, Стефан (2016). «Связи между личностями, стилями и исполнением в компьютерном программировании». Журнал систем и программного обеспечения. 111: 228–241. arXiv:1611.10169. Дои:10.1016 / j.jss.2015.09.011.

дальнейшее чтение

  • Оценка стоимости программного обеспечения с помощью Cocomo II, Барри В. Бём и др., Прентис Холл, 2000. ISBN  978-0-13-026692-7.
  • Разработка продуктов вдвое быстрее: новые правила, новые инструменты, Престон Г. Смит и Дональд Г. Райнертсен, Wiley, 1997. ISBN  978-0-471-29252-4.
  • Производительность программирования, Каперс Джонс, Макгроу-Хилл, 1986. ISBN  978-0-07-032811-2.
  • Оценка стоимости программного обеспечения, Каперс Джонс, Макгроу-Хилл, 2007. ISBN  978-0-07-148300-1.