프로그래밍 생산성

프로그래밍 생산성(소프트웨어 생산성 또는 개발 생산성이라고도 함)은 개별 프로그래머 또는 개발 팀이 소프트웨어 시스템을 구축하고 발전시키는 능력의 정도를 나타냅니다.생산성은 전통적으로 생산된 소프트웨어의 양과 그에 소요되는 비용 사이의 비율을 나타냅니다.여기서 섬세함은 소프트웨어 수량을 정의하는 합리적인 방법을 찾는 데 있습니다.

용어.

생산성은 제조, 조직 심리학, 산업 공학, 전략 경영, 재무, 회계, 마케팅 및 경제와 같은 다양한 분야에서 조사되는 중요한 주제입니다.분석 수준에는 개인, 그룹, 부서, 조직 및 국가 ^[1]수준이 포함됩니다.이러한 다양성 때문에, 비록 한 세기 이상 연구가 수행되었지만, 생산성과 그 영향 요인에 대한 명확한 정의는 없습니다.소프트웨어 엔지니어링에서와 마찬가지로 실제로 생산성을 구성하는 것이 무엇인지에 대한 공통의 합의가 부족한 것은 ^[2]생산성에 대한 실질적인 논의에 있어 주요 장애물로 인식됩니다.다음 정의는 ^[3]용어에 대한 최상의 합의를 설명합니다.

생산성

생산성의 정의에 대해 일반적으로 합의된 사항은 없지만, 생산성이 출력과 입력 사이의 비율을 설명한다는 합의가 있는 것으로 보입니다.

생산성 = 출력 / 입력

그러나 다양한 분야에서 다양한 개념, 특히 입력 및 출력에 대한 서로 다른 측정 단위를 찾을 수 있습니다.제조 업계에서는 일반적으로 생산된 장치의 수와 ^[4]소비된 장치의 수 사이에 직접적인 관계를 사용합니다.비제조업에서는 일반적으로 생산물과 입력물을 비교하기 위해 공수 또는 유사한 단위를 사용합니다.

한 가지 기본적인 합의는 생산성의 의미와 그것을 측정하는 수단이 평가 대상이 되는 상황에 따라 다르다는 것입니다.제조 회사에서 가능한 상황은 다음과 같습니다.^[3]

개별 기계 또는 제조 시스템
제조 기능(예: 조립품)
단일 제품 또는 관련 제품 그룹의 제조 프로세스
공장; 그리고.
그 회사의 전체 공장 시스템

고전적인 생산 공정이 생산성의 직접적인 측정 기준으로 간주되는 한, 특정 품질의 제품이 몇 개의 단위로 생산되는지를 나타내는 것은 간단합니다.지적 작업의 경우 생산성이 훨씬 까다롭습니다.저자, 과학자 또는 엔지니어의 생산성을 어떻게 측정합니까?지식 작업의 중요성이 증가함에 따라(수작업과 반대로)^[5] 많은 연구자들이 비제조 환경에서 적용할 수 있는 생산성 측정 방법을 개발하려고 노력했습니다.지식 작업의 특성은 수작업과 근본적으로 다르므로 단순한 출력/입력 비율 이외의 요소(예: 품질, 적시성, 자율성, 프로젝트 성공, 고객 만족 및 혁신)를 고려해야 한다는 것이 일반적인 의견입니다.그러나 두 분야의 연구 커뮤니티는 아직 ^[1]생산성 측정에 광범위하게 적용되고 수용되는 방법을 확립하지 못했습니다.프로그래밍 생산성의 보다 구체적인 영역에서도 마찬가지입니다.

수익성

수익성과 성과는 밀접하게 연결되어 있으며 실제로는 종종 혼동됩니다.그러나 수익성은 일반적으로 수익과 비용 사이의 비율로 정의됩니다.

수익성 = 매출 / 비용

성과보다 범위가 넓습니다. 즉, 수익성에 영향을 미치는 요인의 수가 생산성에 영향을 미치는 요인의 수보다 큽니다.특히 수익성은 비용이나 가격 인플레이션과 같은 외부 조건에 의해 생산성에 아무런 변화 없이 변경될 수 있습니다.그 외에도, 생산성과 수익성 사이의 상호 의존성은 대개 지연됩니다. 즉, 생산성 향상이 즉각적인 수익성 향상에 반영되는 경우는 거의 없습니다. 장기적으로 실현 가능성이 더 높습니다.

성능

성과라는 용어는 생산성과 수익성보다 훨씬 더 광범위하며 기업의 성공에 영향을 미치는 다양한 요소를 포함합니다.따라서 균형 점수 카드와 같은 잘 알려진 성능 제어 도구는 생산성을 중심적이지만 고유하지 않은 요소로 포함합니다.다른 관련 요소는 고객 또는 이해관계자의 회사에 대한 인식입니다.

효율성 및 효과

효율성과 효율성은 그 자체가 종종 혼동되고, 또한 효율성과 생산성이 종종 혼동되기 때문에 더욱 혼란스러운 용어입니다.효율성과 효율성의 차이는 대개 효율성이 올바른 일을 하는 것이고 효율성은 올바른 일을 하는 것이기 때문에 비공식적으로 설명됩니다.그 밖에도 여러 ^[3]정의가 있지만 효율성은 리소스 활용도를 의미하며 생산성 비율의 필수 입력에 주로 영향을 미친다는 데 동의합니다.한편, 효율성은 대개 고객에게 직접적인 영향을 미치기 때문에 생산성 비율의 산출에 주로 영향을 미칩니다.효과는 "원하는 출력에 도달하는 능력"으로 정의할 수 있습니다.

일반적으로 효율성은 효율성보다 활용률 등에 의해 상당히 쉽게 정량화될 수 있다고 가정합니다.

퀄리티

Tangen은 "결함이 없는 제품이 출력 수준을 높인다는 사실을 제외하고는 품질 개선이 생산성 ^[3]개념에 포함되어서는 안 됩니다."라고 말합니다.그러나 비 소프트웨어 분야, 특히 제조 분야의 대부분의 고전 문헌은 생산성 ^[6]비율에서 출력 품질의 역할에 대해 명시적으로 논의하지 않습니다.비제조 분야의 최근 작업은 지식, 사무실 또는 화이트칼라 작업에 더 중점을 두고 있으므로 ^[5]^[1]^[7]^[8]^[9]품질과 관련하여 품질의 역할에 대해 점점 더 논의하고 있습니다.

Drucker는 지식 작업자의 생산성 평가를 위한 품질의 중요성을 강조합니다. "따라서 지식 작업의 생산성은 우선 품질을 얻는 것을 목표로 해야 하며, 최소 품질이 아니라 최대 품질이 아니더라도 최적을 얻는 것을 목표로 해야 합니다.그래야만 사람들은 다음과 같이 물을 수 있습니다. "볼륨, 일의 양은 얼마입니까?"""^[5]

Saari는 생산성을 ^[8]위한 확장된 공식으로 품질의 중요성을 포착합니다.

총생산성 = (출력품질 및 수량)/(입력품질 및 수량)

그러나 품질을 생산성 결정에 포함시키려는 이러한 노력은 아직 운영 가능한 개념으로 이어지지 않은 것으로 보입니다.현재 비율 계산은 고사하고 "입력 품질 및 수량"뿐만 아니라 모호한 용어인 "출력 품질 및 수량"을 어떻게 계량화할지도 불분명합니다.

최첨단

소프트웨어 개발에서 상황은 상품의 생산보다 더 복잡합니다.소프트웨어 개발은 엔지니어링 프로세스입니다.

코코모 II

Boehm은 소프트웨어 생산성 분야에 체계적으로 접근한 최초의 연구자 중 한 명입니다.그의 비용 추정 모델인 COCOMO(현재는 COCOMO^[10] II)는 표준 소프트웨어 엔지니어링 지식입니다.이 모형에서는 필요한 신뢰성 또는 분석가의 역량과 같은 생산성에 영향을 미치는 요인을 정의합니다.이러한 요인들은 다른 유사한 생산성 접근 방식에서 널리 재사용되었습니다.모델의 나머지 부분은 함수 점과 마지막으로 코드 소스 라인(LOC)을 기반으로 합니다.생산성 척도로서의 LOC의 한계는 잘 알려져 있습니다.

존스의 소프트웨어 생산성

Jones는 소프트웨어 생산성에 관한 책 시리즈의 저자입니다.몇 가지 이론적 고려 사항 외에도 생산성 분석과 관련된 대량의 데이터를 체계적으로 제공하고 통합하는 것이 그의 주된 기여입니다.그의 ^[11]^[12]책 중 적어도 두 권에서, 그는 많은 생산성 요소들을 제공하지만 각 프로젝트에 대해 다른 일련의 요소들이 영향력이 있다고 지적합니다.이러한 요인들은 생산성 평가와 산업 평균과의 비교를 위한 기초를 형성할 수 있습니다.

다음은 이러한 목록 중 하나입니다.

과거 데이터를 통해 소프트웨어 프로젝트에 대한 정량화된 영향을 파악한 20가지 요인은 다음과 같습니다.
사용된 프로그래밍 언어

프로그램 크기

프로그래머와 디자인 인력의 경험

요구사항의 신규성

프로그램 및 데이터의 복잡성

구조화된 프로그래밍 방법의 사용

프로그램 클래스 또는 배포 방법

응용 프로그램 영역의 프로그램 유형

도구 및 환경 조건

기존 프로그램 또는 시스템 개선

기존 프로그램 또는 시스템 유지 관리

기존 모듈 및 표준 설계 재사용

프로그램 생성기

4세대 언어

개발 위치의 지리적 분리

결함 가능성 및 제거 방법

기존 설명서

메인 개발을 시작하기 전에 시제품 제작

프로젝트 팀 및 조직 구조

직원의 사기^[12] 및 보상

기능점

함수점은 1977년 Albrecht에 의해 LOC보다 소프트웨어의 더 나은 크기 측정으로 제안되었습니다.소프트웨어 사양을 기반으로 하기 때문에 코드 자체보다는 소프트웨어 기능의 크기를 측정하는 것을 목표로 합니다.그 이유는 코드의 크기가 기능의 크기뿐만 아니라 프로그래머의 능력에 달려 있기 때문입니다. 더 나은 프로그래머는 동일한 기능에 대해 더 적은 코드를 생성할 것입니다.기능 포인트는 주로 IFPUG(International Function Point User Group)에 의해 주도되는 수년간 여러 재설계를 거쳤습니다.이 그룹은 1200개 이상의 회사가 회원으로 있는 대규모 그룹으로, 이 조치가 상당히 강력하게 수용되고 있음을 보여줍니다.그러나 비즈니스 정보 시스템에만 적용되는 것으로 간주되는 경우가 많기 때문에 많은 영역에서 여전히 실용적인 적용이 부족합니다.

가치 기반 소프트웨어 엔지니어링

몇몇 연구자들은 경제 중심 또는 가치 기반 소프트웨어 엔지니어링을 미래 소프트웨어 엔지니어링 연구의 중요한 패러다임으로 제안했습니다.Bhem과 Huang은 소프트웨어 프로젝트의 비용뿐만 아니라 실제 벌어들인 가치, 즉 ^[13]고객을 위한 가치를 추적하는 것이 중요하다고 지적합니다.그들은 소프트웨어 비즈니스 케이스를 만들고 최신 상태로 유지하는 것이 중요하다고 설명합니다.본질적으로 가치 기반 소프트웨어 엔지니어링은 주로 화폐 단위로 측정되는 고객 가치에 초점을 맞춥니다.

피플웨어

드 마르코와 리스터의^[14] 유명한 책 피플웨어: 생산적인 프로젝트와 팀은 사람과 관련된 요소들의 중요성을 더 많은 청중들의 관심을 끌었습니다.이들은 팀의 생산성에 영향을 미치는 우수 관리 관행과 불량 관리 관행에 대한 많은 소프트웨어 프로젝트 경험을 수집했습니다.그들과 다른 사람들은 이것들이 소프트웨어 엔지니어링의 결정적인 문제라는 것을 보여주었지만 그것들을 일화적으로만 설명할 수 있었습니다.