1) 스토리 포인트는 프로젝트 내 개별 작업의 난이도를 나타내기 위해 프로젝트 관리 및 개발에 사용되는 추정 측정 단위입니다.
이는 팀에서 정의한 추상적 측정 단위로, 각 작업을 완료하는 데 필요한 전반적인 노력을 기반으로 작업을 평가, 이해 및 비교하는 데 사용할 수 있습니다. 스토리 포인트는 작업의 복잡성, 완료하는 데 걸리는 예상 시간, 필요한 리소스 수 등과 같은 요소를 고려합니다.
스토리 포인트는 프로젝트 백로그를 구성하는 데 사용됩니다 . 프로젝트의 각 작업 단위에는 적절한 수의 스토리 포인트가 할당되어 팀이 백로그의 우선 순위를 지정하는 데 도움이 됩니다. 항목에 필요한 스토리 포인트 수는 우선순위를 결정하는 유일한 요소는 아니지만 어떤 작업을 더 빨리 시작해야 하는지 이해하는 데 도움이 됩니다.
2) 스토리 포인트는 SW규모와 비용 등 계약 기준으로 활용할 수 있는가?
스토리 포인트는 정규화된 표준 SW측정단위가 아닙니다. 따라서 스토리 포인트는 측정단위로서 도량형이라는 정형화된 표준 척도가 될 수 없다는 뜻인거죠.
이 측정단위는 상대적인 비교를 통해 동일한 사업내에서 상대적인 규모가 크다 거나 적다라는 수준으로 사용될 수는 있습니다.
따라서, LOC 또는 FP와 같은 정규화된 표준 척도로서의 역할은 못한다는 의미입니다.
2. 기능점수란?
사용자 관점에서 측정된 소프트웨어 기능의 양으로서, 사용 자에게 제공되는 소프트웨어 기능의 규모를 측정하는 단위이다. 소프트웨어 기능은 사용자 관점에서 갖는 논리적 의미에 따라 크게 데이터 측면의 기능과 트랜잭션 측면의 기능으로 구분된다. 이들을 다시 세분하면 데이터 기능에는 내부논리파일(ILF)과 외부연계파일(EIF)의 2가지 유형이 있으며, 트랜잭션 기능에는 세부적으로 외부입력(EI), 외부출력(EO), 외부조회(EQ)의 3가지 유형이 있다.
이 측정단위는 SW측정단위로 국제표준으로 정립되어 있으며, 어떤 조직이나 프로젝트에 무관하게 SW규모를 측정하는 정규화된 측정단위라는 의미입니다.
따라서, 우리나라를 비롯한 전세계적으로 SW규모와 비용을 산출할때 사용되며, 이는 규모당 단가 형태로 사용되거나, 규모와 공수를 활용한 표준 생산성 기준을 활용하여 소요공수를 산출 후 결정된 노임단가를 적용하여 사업예산을 산출하게 됩니다.
3. 결론
스토리 포인트 지표가 팀 수준의 계획에 유용하다는 것입니다. 그러나 팀간 또는 조직간 서로 비교하거나 ISBSG 데이터와 같은 산업 데이터를 비교하는 등 집계된 수준에서는 사용할 수 없습니다.
이는 기업이 비유동자산을 구매하거나, 유효수명이 당회계년도를 초과하는 기존의 비유동자산에 대한 투자에 돈을 사용할 때 발생한다. CAPEX는 회사가 장비, 토지, 건물 등의 물질자산을 획득하거나 이를 개량할 때 사용한다. 회계에서 Capex는 자산계정에 추가하므로 (자본화), 자산내용(세금부과에 적용되는 자산가치)의 증가를 가져온다. CAPEX는 일반적으로 현금흐름표에서 장비와 토지자산에 대한 투자 등에서 볼 수 있다.
2. Opex
'업무지출' 또는 '운영비용'이라고도 하며 갖춰진 설비를 운영하는데 드는 제반 비용을 말한다.
OPEX는 인건비, 재료비, 수선유지비와 같은 직접 비용과 제세공과금 등의 간접 비용으로 구성되어 있으며 통상 CAPEX와 함께 대조적으로 많이 쓰이는 용어다. OPEX가 높다는 것은 기존의 생산설비등이 노후화되었다고 볼 수 있다.
누구나 기능 점수를 계산할 수 있습니다! 필요한 것은 기능점수 측정 규칙에 대한 이해와 실무 측정 경험을 보유하고 있어야 합니다. 이를 감안할 때 카운터는 기술 인력 또는 사용자(고객, 고객 또는 이러한 시스템을 사용하는 사람들)이어야 합니까? 조직 의 모든 사람이 기능 점수를 계산해야 합니까?
기능점수 측정결과에 대한 성공과 실패에서 얻은 몇 가지 교훈은 다음과 같습니다.
기술자는 기능 점수를 계산해야 합니까?
기술 인력은 오랫동안 주요 기능 점수 카운터였습니다. 이것은 의미가 있습니다. 기술 인력은 견적을 생성하라는 요청을 받았을 때 종종 사용했습니다. 좀 더 미래 지향적인 기술 관리자는 기능점수를 사용하여 조직의 생산성을 분석하고 활용 했습니다. 진정으로 진보적인 사고를 하는 기술자들은 응용 프로그램 아키텍처를 개발할 때 기능을 할당하거나 회사의 응용 프로그램 포트폴리오에 있는 응용 프로그램에 대한 유지/폐기/재설계 결정을 내리기 위해 기능점수를 사용했습니다. 기술 인력은 계속해서 기능 점수 카운팅 시 참여 하고 있습니다.
불행하게도 기술자들에게는 기능 점수 계산과 관련하여 한 가지 큰 맹점이 있습니다. 그들은 기능점수 카운트가 전체 프로젝트의 노력과 관련되어야 한다는 것을 알고 있습니다. 따라서 그들은 계산의 각 세부 사항이 해당 세부 사항과 관련되어 기억했거나 예상되는 노력과 일치하도록 시도합니다. 예를 들어, 그들은 도움말 시스템을 개발하는 데 몇 주가 걸렸으며 IFPUG 4.0이 전체 응용 프로그램의 도움말 기능에 대해 8개의 기능 포인트(낮은 복잡성 EQ의 경우 3개, 낮은 복잡성 EIF의 경우 5개)만 산정된다는 사실에 불평을 하는 경우도 많이 발생하지요.
사용자(클라이언트 또는 고객)가 기능 점수를 계산해야 합니까?
초기 GUIDE 계산 매뉴얼에는 시니어 레벨 사용자도 기능 점수를 계산하도록 훈련 받을 수 있다고 언급되어 있습니다. 그것에 대해 의심의 여지가 없습니다. 기능 포인트 계산은 회계와 매우 유사합니다. 회계사는 예를 들어 FASB(재무회계기준위원회)의 규칙을 적용하여 회사의 재무 건전성을 측정해야 합니다. 이러한 규칙에는 몇 가지 이론적 근거가 있지만 종종 특수 이해 관계에 의한 타협과 정치판단의 결과를 야기하기도 합니다. 이는 애플리케이션에 IFPUG 규칙을 적용하는 것과 비슷합니다.
사용자가 기능 점수를 계산하려는 이유는 무엇입니까? 복잡한 시스템을 개발하는 것은 거의 모든 비즈니스의 핵심 역량이 되었습니다. 사용자는 시스템에서 필요한 기능 요구사항을 확보하기 위해 이러한 개발자와 협상 또는 협의가 있어야 합니다. 이것은 올바른 기능점수 측정에 필요한 사항인거죠.
고위급 사람들이 계산을 해야 합니까?
누구든지 기능 점수를 계산하도록 훈련받을 수 있기 때문에 자연스러운 질문은 고위급 직원에게 할당할지 여부입니다. 대답은 일반적으로 예입니다. 첫째, 고위급 직원은 일반적으로 기능의 주요 부분이 무시되지 않도록 하기 위해 질문해야 할 사항을 알고 있습니다. 또한 경험이 적은 사람이 간과할 수 있는 문제점을 극복할 수 있습니다.
조직에서 몇 명이나 세어야 합니까?
기능 점수 계산 책임을 할당하는 세 가지(모든 사람, 소그룹 또는 특정된 한사람 ) 가능한 방법이 있습니다:
1) 모든 사람에게 기능점수를 측정하도록 한다면, 모든 사람이 기능 포인트에 익숙해야 정확하게 계산할 수 있는데, 그러나 정확한 결과 도출은 극히 드물다고 보시면 됩니다. 이유는 기능점수 측정이 일상업무가 아님에 따라 6개월 이상 개발 작업을 한 다음 다시 계산한다고 하면 그때까지 그들은 기능점수 규칙을 기억하지 못한 경우가 대다수입니다. 지속적인 재교육은 모든 사람으로부터 정확한 카운트를 얻을 수 있는 유일한 방법이며 이는 비용 효율적이지 않은 경우가 많습니다.
2) 대규모 조직의 경우 기능 점수 계산 및 기타 추정 활동과 관련된 소그룹을 운영하는 것이 이상적입니다. 그룹은 규칙을 최신 상태로 유지하기 위해 충분히 자주 계산해야 합니다. 프로젝트로부터 독립함으로써 그들은 프로젝트에 대해 덜 편향된 피드백을 제공할 수 있을 것입니다. 그룹으로서 그들은 어려운 계산 상황에서 서로 도움을 구할 수 있고 따라서 그들의 계산을 일관되게 유지할 수 있습니다.
3) 한 사람을 조직의 기능 포인트 전문가로 지정하는 것과 관련된 강력한 장점과 단점이 있습니다. 작업량이 적은 경우 한 사람을 할당하는 것이 더 큰 조직에서 그룹을 할당하는 것과 같은 이점이 있습니다. 그러나 기능 점수 전문가는 계산 규칙에 대한 다양한 해석을 반박할 사람이 필요합니다. 이러한 상황에서 IFPUG 로부터 전문가 자격을 획득한 사람의 참여를 필수로 요구합니다. 업계 컨설턴트 중 한 명과의 관계를 유지하는 것이 아마도 필수일 것입니다.
카운트 아웃소싱의 이점은 무엇입니까?
기능 점수 계산의 아웃소싱에는 다른 형태의 아웃소싱과 관련된 모든 이점이 있습니다. 이는 신뢰성, 일관성 및 독립성 문제를 해결할 수 있는 거지요.
전문성 - 주요 기능 포인트 컨설턴트는 많은 조직과 다양한 기술에 대한 경험을 가지고 있습니다. 기능 점수 계산 외에도 Software Composition Technologies는 프로젝트 추정 및 계획에 대한 광범위한 경험을 보유하고 있습니다. 측정 프로그램 및 소프트웨어 개발 프로세스 전체에서 기능 포인트 분석이 적절하게 활용되고 있는지 확인할 수 있습니다.
최신 지식 - 기능 점수 계산을 최신 상태로 유지하는 것은 대부분의 사내 실무자에게 문제입니다. 몇 달에 한 번씩만 시스템을 세는 경우 더 복잡한 규칙에 대한 지식이 사라지기 시작합니다. 그들은 종종 IFPUG 컨퍼런스 또는 기타 교육 행사에서 지식을 업데이트할 시간과 예산이 부족합니다. Software Composition Technologies의 카운터는 자주 그리고 정기적으로 회의에 참여합니다.
신뢰성 - 많은 상황에서 사내 카운터의 신뢰성이 문제입니다. 외부 컨설턴트는 전문 지식과 최신 정보로 인해 더 큰 신뢰를 받는 경우가 많습니다. 때때로 그들이 외부인이라는 단순한 사실만으로도 신뢰도가 높아집니다. 외부 컨설턴트는 IFPUG 인증 기능 점수 전문가여야 합니다. 많은 사람들에게 이것은 중요한 자격 증명입니다.
일관성 - 일관성은 측정값을 성공적으로 사용하는 열쇠입니다. 일관성을 위한 한 가지 요구 사항은 계산 관행과 관련하여 서로 지속적으로 소통하는 소수의 계수기 그룹을 사용하는 것입니다. 또한 이 그룹은 기능 점수 계산 커뮤니티 전체, 즉 IFPUG의 회원 및 참여와 관련이 있어야 합니다.
Independence- 편향은 기능 점수 계산에서 문제가 될 수 있습니다. 프로젝트 담당자는 그들이 제공하는 시스템의 크기에 따라 평가되기 때문에 계산을 과장할 수 있습니다. 프로젝트 고객은 더 빠르고 저렴한 배송을 위해 크기를 과소평가할 수 있습니다. 카운트 및 관련 추정치의 정확성만으로 판단되는 사람이 필요합니다. 이것이 독립 컨설턴트의 역할입니다.
리소스 확보 - 많은 개발 그룹에서 계산은 다른 프로젝트 책임이 있는 개발자가 수행합니다. 그들은 일반적으로 이러한 다른 작업을 수행해야 한다는 압박을 받고 있습니다. 그들은 종종 직업 안정이나 승진이 기능 점수 계산과 밀접하게 일치한다고 생각하지 않습니다. 카운트 아웃소싱은 종종 이러한 개발자와 관리자를 더 행복하게 만듭니다.
투표와 마찬가지로 사업 발주 전에 자주 집계해야 합니다! 프로젝트가 제공하는 것을 더 빨리 정량화 할수록 더 빨리 제어할 수 있습니다. 전통적으로 많은 실무자들은 제품 설계(또는 외부 설계, 동일한 것의 다른 이름)가 완료될 때까지 기능 점수 계산을 할수 없다고 믿었습니다.
IFPUG 구성원은 개발 수명 주기 초기에 기능 점수를 계산할 수 있는 능력의 중요성을 오랫동안 인식해 왔습니다. IFPUG 4.0에는 요구 사항이 확정되면 기능 점수를 계산할 수 있는 규칙과 지침이 있습니다. 많은 실무자들은 수명 주기에서 더 일찍 기능 점수 크기를 추정할 수 있는 휴리스틱을 사용합니다. 아래 단락에서는 수명 주기의 다양한 지점에서 발생할 수 있는 기능 점수 추정 및 계산에 대해 설명합니다. 모든 사람들이 서로 다른 라이브 사이클을 사용하기 때문에 단계는 관련 결과물에 대한 프로젝트의 진행 측면에서 설명됩니다.
수명 주기가 타당성 조사와 같은 것으로 시작되는 경우 일반적으로 이 시점에서 기능 점수를 계산하는 것은 불가능합니다. 그러나 기능 점수는 현재 코드 라인 또는 노력을 추정하는 데 사용되는 방법과 동일한 기술을 사용하여 추정할 수 있습니다. 유사한 프로젝트가 2,000 기능 점수 였다면 현재 가장 좋은 추측은 이 프로젝트도 2,000 기능 점수라는 것입니다.
요구 사항을 수집하는 동안 기능 점수의 크기 추정치를 지속적으로 세분화할 수 있습니다. 많은 프로젝트에서 논리적 데이터 모델이 개발됩니다. 논리적 데이터 모델에 대한 사람들의 정의는 다양하지만 어느 시점에서 이 모델은 속성이 지정되지 않으며 제3정규형도 아닙니다. 그러나 이 시점에서 분석가는 엔터티를 추가, 변경, 삭제 및 표시하는 프로세스가 필요한 엔터티를 식별하기 시작할 수 있습니다. Yourdon 컨텍스트 다이어그램과 동등한 것이 생성된 경우 사용자 및 외부 시스템과의 상호 작용이 지정됩니다. 이 시점에서 식별된 트랜잭션이 모두 평균 복잡도라고 가정하면 기능 포인트 크기를 적절하게 추정할 수 있습니다. 수명 주기의 이 시점에서도 일반적으로 공정한 정확도로 가치 조정 요인을 예측하는 것이 가능합니다.
비즈니스 요구 사항이 완료되면 응용 프로그램의 기능 점수를 정확하게 계산할 수 있습니다. 이 시점에서 논리적 데이터 모델은 완전히 특성화되어야 합니다. 화면 및 보고서를 포함한 모든 시스템 상호 작용을 식별하고 관련 데이터 항목을 지정해야 합니다. 지금은 화면이나 보고서를 포맷할 필요가 없습니다.
이미 언급한 바와 같이 외부 설계 또는 제품 설계에 따라 정확한 기능 점수를 얻을 수 있습니다. 물론 요구 사항 완료 시 정확한 카운트를 받았어야 합니다. 지금은 요구 사항의 변동성과 프로젝트에 미치는 영향을 고려하기 시작할 때입니다 . 가장 단순한 유형의 요구 사항 변동성은 범위 증가입니다. 요구 사항 종료 시 프로젝트를 1,000 기능 점수로 측정한 다음 제품 설계 후에 1,500 기능 점수를 측정하면 범위 차질(Scope Creep)이 50% 이상입니다.
다른 형태의 요구 사항 변동성은 더 교활할 수 있습니다. 예를 들어 요구 사항 종료 시 기능 점수 1,000점, 프로젝트 설계 종료 시 기능 점수 1,000점을 측정할 수 있습니다. 불행하게도 이러한 이후 기능 점수의 대부분은 요구 사항에서 식별된 기능과 완전히 다른 기능에 대한 것입니다. 어떤 사람들은 이것을 파손이라고 부릅니다. 이름이 무엇이든 추적해야 합니다. 이러한 변화가 수명 주기에서 멀어질수록 이러한 변화에 더 많은 비용이 듭니다. 그러나 기능 점수 크기는 변경되지 않았기 때문에 이러한 변경의 영향은 종종 무시됩니다. 이러한 변화는 향상 기능 점수를 추적해야 합니다. 이러한 방식으로 프로젝트를 재평가해야 할 때 영향을 적절하게 고려할 수 있습니다.
이론상으로는 제품 설계 종료 시점과 승인 테스트 종료 시점 사이에 기능 점수수에 변화가 없어야 합니다. 물론 이론적으로는 이론과 실제 사이에 차이가 없습니다. 실제로는 큰 차이가 있습니다! 이 구현 및 테스트 시간 동안 변경 사항을 적용하는 데 점진적으로 더 많은 비용이 듭니다. 매우 자주 사용자와 프로젝트 관리자는 이 시간 동안 변경 요청, 기능, 비용 및 일정을 교환합니다. 기능 점수는 이러한 협상을 정량화하는 데 사용할 수 있습니다. 그러나 올바르게 사용해야 합니다. 100 기능 포인트 향상을 기능 100 기능 포인트 감소로 바꾸는 것은 현명하지 않습니다. 삭제될 100개의 기능 점수에 이미 소비된 작업도 고려해야 합니다. 다시 말하지만, 강화 기능 포인트를 사용하면 모든 참가자가 이 프로세스를 더 쉽게 수행할 수 있습니다.
프로젝트 종료 시 기능 점수를 업데이트하는 것이 좋습니다. 프로젝트는 향후 프로젝트 추정치를 보다 정확하게 만든다는 생각으로 검토되어야 합니다. 애플리케이션 크기는 필요한 지원 수준을 결정하는 요소이기도 합니다. 사용자 커뮤니티는 애플리케이션과 관련된 비즈니스 가치가 이를 지원하는 데 필요한 노력의 가치가 있는지 여부를 결정해야 합니다.
코드라인수는 응용 프로그램 크기를 측정하는 전통적인 방법입니다. 어떤 사람들은 소프트웨어 개발자가 실제로 수행하는 것, 즉 코드 라인을 작성하는 것을 측정하기 때문에 기능 점수에 추가하여 코드 라인을 사용합니다.
일부 전문가들은 코드 라인이 부적절하다고 말합니다. Capers Jones는 "1995년부터 생산성 및 품질 연구를 위한 일련의 코드 메트릭스를 전문적인 과실로 간주할 것"이라고 선언했습니다.
코드 라인 수를 세는 것은 개발자의 관점에서 소프트웨어를 측정하는 것입니다. 기능 점수는 화면, 보고서 및 기타 외부 개체를 기반으로 하므로 이 측정은 사용자의 관점을 취합니다.
코드 라인수가 생산성의 주요 척도인 경우 개발자들은 코드라인수를 많이 생산하려고 하고 재사용 기회를 무시하는 등의 오류를 범하는 단초가 되기도 합니다.
반면에, 기능 점수가 생산성의 주요 척도인 경우 개발자의 기능 생산이 증가하는 경향이 있습니다. 물론 이 기능이 향상된 비즈니스 가치를 제공하는지 여부를 평가하는 것은 사용자의 책임입니다.
코드 라인에는 다른 기술적인 문제가 있습니다. IBM은 BAL, COBOL 및 PL/I가 사용되는 이 기종 개발 환경이 현실화되기 시작했기 때문에 기능 점수를 활용한 측정을 장려했습니다.
이제 거의 모든 프로젝트는 여러 언어를 혼합하여 사용하고 있습니다. 또한 대부분의 최신 개발 프로젝트는 다양한 언어를 사용합니다.
또한 코드 라인이 무엇인지에 대한 표준 정의가 없습니다. 빈 줄이 중요합니까? 댓글이 중요합니까? 데이터 선언이 포함되어 있습니까? 명령문이 여러 줄에 걸쳐 기술하면 어떻게 됩니까? 소프트웨어 엔지니어링 연구소(Software Engineering Institute)와 같은 조직에서는 카운팅을 표준화하기 위한 몇 가지 지침을 발표했지만 IFPUG는 기능 점수에 대해 오너십을 가지고 있는 반면에 코드 라인수에 대한 오너쉽이 어느누구도 가지지 않는다는 점도 향후 소프트웨어 규모측정 방법으로 무엇이 많이 활용될지 판단가능하며, 현재 SW규모측정방법의 국제표준은 기능점수 방법 뿐입니다.
예. 결론적으로 정리하면 응용 프로그램을 측정하는 데 사용할 수 있으며 개체 지향 개발이 사용되지 않은 것과 크기가 동일하다는 것입니다.
이는 애플리케이션의 기능 점수 측정은 애플리케이션 개발에 사용된 기술과 독립적이기 때문입니다. 그러나 객체 지향의 사용은 애플리케이션을 구축하는 프로젝트의 기능 점수에 영향을 미치는 경향이 있습니다.
최소한 객체 지향 개발 기술을 사용하면 개발자가 사전 구축된 Windows 편집 컨트롤 등을 사용할 수 있습니다. 객체 지향이 완전히 수용되면 개발자는 주요 기능을 응용 프로그램에 통합할 수 있습니다. 예를 들어 OLE 자동화를 사용하면 응용 프로그램이 Microsoft Project 버전 4.0의 기능을 완전히 활용할 수 있습니다. 이러한 상황에서 계산하려면 훌륭한 엔지니어링 판단과 경험이 필요합니다.
IFPUG(International Function Point Users Group)는 개체 지향 기술을 사용하여 개발된 애플리케이션의 개수를 보여주는 사례 연구를 참고하시며 도움이 됩니다.
예. 가장 단순한 경우에 사용자는 자신이 중앙 컴퓨터에서 실행되는 프로그램을 사용하고 있는지 또는 네트워크를 통해 다양한 컴퓨터에서 실행 중인 일련의 프로그램을 사용하고 있는지 모를 수 있습니다. 사실, 멋진 클라이언트/서버 세계에서는 존재하는지도 몰랐던 컴퓨터의 오류로 인해 애플리케이션이 이상 종료 (비정상 종료에 도달)할 수 있습니다! 이것은 클라이언트 -서버 시스템이 다른 시스템과 마찬가지로 계산될 수 있다는 강력한 주장을 제시합니다 . 불행하게도 클라이언트/서버는 카운팅 프로세스에 약간의 복잡성을 야기합니다.
기술 인프라의 개발을 설명하는 것은 종종 어려운 일입니다. 기술 인프라는 데이터베이스 관리자, 미들웨어, API 및 개발자가 사용하는 기타 구성 요소로 구성될 수 있습니다. 이 인프라를 설치하는 것은 종종 완전히 별개의 프로젝트입니다. 이 프로젝트와 관련된 기능 점수가 있습니까? 그렇다면 애플리케이션 개발자가 인프라의 사용자인 것처럼 카운트가 수행됩니까? 물론 기업의 비즈니스 사용자 중 일부는 최종 사용자 애플리케이션 개발을 수행할 때 이 인프라와 직접 상호 작용할 수 있습니다. 이로 인해 이전 질문에 대한 답변이 변경됩니까?
우리의 관심을 애플리케이션 프로그램으로 제한할 때에도 클라이언트/서버 시스템 개발 프로젝트의 경계를 식별하는 것은 종종 까다로울 수 있습니다.
그러나, 결론적으로 클라이언트와 서버는 기술적으로 분리된 것으로, 사용자 관점에서는 하나의 경계로 식별하고 있습니다.
예. 기능 점수가 처음 개발되었을 때 그래픽 사용자 인터페이스(GUI)가 있는 시스템에는 적용되지 않았습니다. GUI가 있는 시스템은 없었습니다! 이러한 GUI 시스템을 계산하는 방법에 대해 기능점수 측정자간에 어느 정도 의견 차이가 있었습니다.
IFPUG는 Function Point Counting Practices Manual의 릴리스 4.0을 완료했습니다. 여기에는 GUI 기반 시스템 계산에 대한 공식 규칙과 광범위한 예제가 포함되어 있습니다. 그 후 IFPUG는 전체 GUI 기반 시스템의 수를 포함하는 사례 연구를 생성했습니다.
안타깝게도 20년 전까지만 해도 GUI 등 새로운 규칙에 익숙하지 않고, 현재 기술을 반영하도록 과정 자료를 업데이트하지 않은 실무자를 여전히 찾을 수 있습니다.
70년대 후반에 IBM은 소프트웨어 개발 노력을 추정하기 위해 언어 독립적 접근 방식을 개발할 필요성을 느꼈습니다. 직원 중 한 명인 Allan Albrecht에게 이 접근 방식을 개발하도록 지시했습니다. 결과는 기능 점수 기술이었습니다.
80년대 초반에 기능 점수 기법이 개선되었고 IBM의 GUIDE 조직에서 측정 매뉴얼을 제작했습니다. IFPUG(International Function Point Users Group)는 80년대 후반에 설립되었습니다. 이 조직은 자체 측정 실뮤 매뉴얼을 제작했습니다. 1994년에 IFPUG는 Counting Practices Manual의 릴리스 4.0을 제작했습니다. GUIDE 간행물과 IFPUG 간행물의 각 릴리스에는 Albrecht가 원래 제시한 기술에 대한 개선 사항이 포함되어 있지만 항상 그의 원래 생각과 일치한다고 주장했습니다. 사실, Allan Albrecht 의 최초 출판 이후 거의 20년이 경과한 것을 고려하면 그 내용이 매우 비슷했습니다.
80년대와 90년대 동안 몇몇 사람들은 Albrecht가 수행한 작업을 실질적으로 확장하거나 완전히 대체하기 위한 기능 점수 측정 기술을 제안했습니다. 이들 중 일부는 이 FAQ에서 간략하게 논의될 것입니다. 본 자료의 FAQ는 IFPUG 릴리스 4.0 규칙을 기준으로 개발된 것입니다.
기능 점수는 컴퓨터 응용 프로그램 및 이를 구축하는 프로젝트의 크기를 측정한 것입니다. 크기는 기능적 또는 사용자 관점에서 측정 됩니다. 응용 프로그램을 개발하는 데 사용되는 컴퓨터 언어, 개발 방법론, 기술 또는 프로젝트 팀의 능력과는 별개입니다. Albrecht가 원래 노력을 예측하기 위해 기능 점수 측정 기준이 개발한 것은 단순히 기능 점수가 일반적으로 개발 노력의 주요 동인이라는 사실에 귀결된 것입니다.
기능 점수는 일반적으로 크기가 각각의 기능 규모를 측정하는 중요한 요소이지만 응용 프로그램을 개발하기 위한 노력이나 비즈니스 가치를 완벽하게 측정하는 것은 아닙니다.
이것은 종종 건물 거래에 대한 비유로 설명됩니다. 3,000평방 피트의 집은 일반적으로 6,000평방 피트의 집을 짓는 것보다 더 저렴합니다. 그러나 대리석 욕실 및 타일 바닥과 같은 많은 속성으로 인해 실제로 작은 집이 더 비쌀 수 있습니다. 위치 및 침실 수와 같은 다른 요소도 작은 집을 거주지로 더 가치 있게 만들 수 있습니다.
Bill Hufschmidt 는 항상 기능 점수의 처음 세 글자가 FUN이라고 강조합니다. 기능 점수 계산을 즐기고 그것을 근거로 정당화할 수 있는 사람들은 그렇게 해야 합니다. 다음은 더 어려운 이유입니다.
생산성 측정 -- 많은 경영진은 핵심 사업과 상관없이 소프트웨어 사업에도 종사하고 있다는 결론에 도달했습니다. 월별 주제별로 생성된 기능 점수에 대한 몇 가지 파생된 결과를 계산하면 그들이 얼마나 잘하고 있는지 알 수 있습니다.(예를 들면, OO FP/MM)
추정 개발 및 지원 -- 처음부터 기능 점수는 추정 기법으로 사용되었습니다. 추정은 애플리케이션 개발을 정당화하는 비용 편익 분석에 분명히 필요합니다. 정량적 타당성이 필요하지 않은 전략적 프로젝트라도 적절한 인력 배치를 위해서는 정확한 추정이 필요합니다.
아웃소싱 계약 모니터링 -- 정보시스템의 요구 사항의 상당 부분을 아웃소싱하는 회사는 아웃소싱 업체가 약속한 수준의 지원 및 생산성 향상을 제공하는지 궁금합니다. CSC 및 IBM 글로벌 서비스와 같은 아웃소싱 업체는 기능 점수를 사용하여 이러한 영역에서 계약 기준의 적정성을 입증합니다.
정보시스템 관련 비즈니스 결정 추진 -- 기업은 애플리케이션 및 프로젝트 포트폴리오를 분석해야 합니다. 기능 점수의 크기는 각 애플리케이션 및 프로젝트에 대해 추적해야 하는 속성입니다. 다른 데이터와 함께 이를 통해 응용 프로그램의 유지, 폐기 및 재 설계에 관한 결정을 내릴 수 있습니다.
기타 측정 값 정규화 -- 소프트웨어 사업의 적정 공수, 적정 비용 등에 대한 판단을 할때 기능 점수의 크기가 필요한 경우가 많습니다. 예를 들어, 100 FP 시스템에서 100개의 결함이 발생되면 좋은 소식이 아닙니다. 10,000 FP규모의 시스템에서 동일한 100개의 전달된 결함을 받아들이는 것이 훨씬 더 쉽습니다.
1. 스토리 포인트란?
1) 스토리 포인트는 프로젝트 내 개별 작업의 난이도를 나타내기 위해 프로젝트 관리 및 개발에 사용되는 추정 측정 단위입니다.
이는 팀에서 정의한 추상적 측정 단위로, 각 작업을 완료하는 데 필요한 전반적인 노력을 기반으로 작업을 평가, 이해 및 비교하는 데 사용할 수 있습니다. 스토리 포인트는 작업의 복잡성, 완료하는 데 걸리는 예상 시간, 필요한 리소스 수 등과 같은 요소를 고려합니다.
스토리 포인트는 프로젝트 백로그를 구성하는 데 사용됩니다 . 프로젝트의 각 작업 단위에는 적절한 수의 스토리 포인트가 할당되어 팀이 백로그의 우선 순위를 지정하는 데 도움이 됩니다. 항목에 필요한 스토리 포인트 수는 우선순위를 결정하는 유일한 요소는 아니지만 어떤 작업을 더 빨리 시작해야 하는지 이해하는 데 도움이 됩니다.
2) 스토리 포인트는 SW규모와 비용 등 계약 기준으로 활용할 수 있는가?
스토리 포인트는 정규화된 표준 SW측정단위가 아닙니다. 따라서 스토리 포인트는 측정단위로서 도량형이라는 정형화된 표준 척도가 될 수 없다는 뜻인거죠.
이 측정단위는 상대적인 비교를 통해 동일한 사업내에서 상대적인 규모가 크다 거나 적다라는 수준으로 사용될 수는 있습니다.
따라서, LOC 또는 FP와 같은 정규화된 표준 척도로서의 역할은 못한다는 의미입니다.
2. 기능점수란?
사용자 관점에서 측정된 소프트웨어 기능의 양으로서, 사용 자에게 제공되는 소프트웨어 기능의 규모를 측정하는 단위이다. 소프트웨어 기능은 사용자 관점에서 갖는 논리적 의미에 따라 크게 데이터 측면의 기능과 트랜잭션 측면의 기능으로 구분된다. 이들을 다시 세분하면 데이터 기능에는 내부논리파일(ILF)과 외부연계파일(EIF)의 2가지 유형이 있으며, 트랜잭션 기능에는 세부적으로 외부입력(EI), 외부출력(EO), 외부조회(EQ)의 3가지 유형이 있다.
이 측정단위는 SW측정단위로 국제표준으로 정립되어 있으며, 어떤 조직이나 프로젝트에 무관하게 SW규모를 측정하는 정규화된 측정단위라는 의미입니다.
따라서, 우리나라를 비롯한 전세계적으로 SW규모와 비용을 산출할때 사용되며, 이는 규모당 단가 형태로 사용되거나, 규모와 공수를 활용한 표준 생산성 기준을 활용하여 소요공수를 산출 후 결정된 노임단가를 적용하여 사업예산을 산출하게 됩니다.
3. 결론
스토리 포인트 지표가 팀 수준의 계획에 유용하다는 것입니다. 그러나 팀간 또는 조직간 서로 비교하거나 ISBSG 데이터와 같은 산업 데이터를 비교하는 등 집계된 수준에서는 사용할 수 없습니다.
1. Capex
미래의 이윤을 창출하기 위해 지출한 비용을 말한다.
이는 기업이 비유동자산을 구매하거나, 유효수명이 당회계년도를 초과하는 기존의 비유동자산에 대한 투자에 돈을 사용할 때 발생한다. CAPEX는 회사가 장비, 토지, 건물 등의 물질자산을 획득하거나 이를 개량할 때 사용한다. 회계에서 Capex는 자산계정에 추가하므로 (자본화), 자산내용(세금부과에 적용되는 자산가치)의 증가를 가져온다. CAPEX는 일반적으로 현금흐름표에서 장비와 토지자산에 대한 투자 등에서 볼 수 있다.
2. Opex
'업무지출' 또는 '운영비용'이라고도 하며 갖춰진 설비를 운영하는데 드는 제반 비용을 말한다.
OPEX는 인건비, 재료비, 수선유지비와 같은 직접 비용과 제세공과금 등의 간접 비용으로 구성되어 있으며 통상 CAPEX와 함께 대조적으로 많이 쓰이는 용어다. OPEX가 높다는 것은 기존의 생산설비등이 노후화되었다고 볼 수 있다.
1. 업무 분류기준 마련 : 운영업무와 유지보수업무를 세부적인 서비스 단위로 분류
2. 서비스 공수 산출 : 운영업무와 유지보수업무 단위별 특정 기간동안 서비스 제공을 위해 투입된 공수 산출
3. 서비스 업무량 산출 : 서비스 유형별 건수 산출
4. 대가산정 기준 마련 : 투입공수 산출 방법과 애플리케이션 규모 산출 방법 마련
5. 표준 단가 개발 : 통계기법을 이용하여 서비스 유형별 표준 단가 개발
6. SLA 기준 마련
7. 대가산출모델 개발
8. 파일럿 수행을 통한 적정성 검증
9. 표준 대가체계 완성 및 적용
기타 필요한 항목은 첨삭될 수 있음
보다 구체적인 문의는 홈페이지의 연락처를 참고하시기 바랍니다.
누가 기능 점수를 계산할 수 있습니까?
누구나 기능 점수를 계산할 수 있습니다! 필요한 것은 기능점수 측정 규칙에 대한 이해와 실무 측정 경험을 보유하고 있어야 합니다. 이를 감안할 때 카운터는 기술 인력 또는 사용자(고객, 고객 또는 이러한 시스템을 사용하는 사람들)이어야 합니까? 조직 의 모든 사람이 기능 점수를 계산해야 합니까?
기능점수 측정결과에 대한 성공과 실패에서 얻은 몇 가지 교훈은 다음과 같습니다.
기술자는 기능 점수를 계산해야 합니까?
기술 인력은 오랫동안 주요 기능 점수 카운터였습니다. 이것은 의미가 있습니다. 기술 인력은 견적을 생성하라는 요청을 받았을 때 종종 사용했습니다. 좀 더 미래 지향적인 기술 관리자는 기능점수를 사용하여 조직의 생산성을 분석하고 활용 했습니다. 진정으로 진보적인 사고를 하는 기술자들은 응용 프로그램 아키텍처를 개발할 때 기능을 할당하거나 회사의 응용 프로그램 포트폴리오에 있는 응용 프로그램에 대한 유지/폐기/재설계 결정을 내리기 위해 기능점수를 사용했습니다. 기술 인력은 계속해서 기능 점수 카운팅 시 참여 하고 있습니다.
불행하게도 기술자들에게는 기능 점수 계산과 관련하여 한 가지 큰 맹점이 있습니다. 그들은 기능점수 카운트가 전체 프로젝트의 노력과 관련되어야 한다는 것을 알고 있습니다. 따라서 그들은 계산의 각 세부 사항이 해당 세부 사항과 관련되어 기억했거나 예상되는 노력과 일치하도록 시도합니다. 예를 들어, 그들은 도움말 시스템을 개발하는 데 몇 주가 걸렸으며 IFPUG 4.0이 전체 응용 프로그램의 도움말 기능에 대해 8개의 기능 포인트(낮은 복잡성 EQ의 경우 3개, 낮은 복잡성 EIF의 경우 5개)만 산정된다는 사실에 불평을 하는 경우도 많이 발생하지요.
사용자(클라이언트 또는 고객)가 기능 점수를 계산해야 합니까?
초기 GUIDE 계산 매뉴얼에는 시니어 레벨 사용자도 기능 점수를 계산하도록 훈련 받을 수 있다고 언급되어 있습니다. 그것에 대해 의심의 여지가 없습니다. 기능 포인트 계산은 회계와 매우 유사합니다. 회계사는 예를 들어 FASB(재무회계기준위원회)의 규칙을 적용하여 회사의 재무 건전성을 측정해야 합니다. 이러한 규칙에는 몇 가지 이론적 근거가 있지만 종종 특수 이해 관계에 의한 타협과 정치판단의 결과를 야기하기도 합니다. 이는 애플리케이션에 IFPUG 규칙을 적용하는 것과 비슷합니다.
사용자가 기능 점수를 계산하려는 이유는 무엇입니까? 복잡한 시스템을 개발하는 것은 거의 모든 비즈니스의 핵심 역량이 되었습니다. 사용자는 시스템에서 필요한 기능 요구사항을 확보하기 위해 이러한 개발자와 협상 또는 협의가 있어야 합니다. 이것은 올바른 기능점수 측정에 필요한 사항인거죠.
고위급 사람들이 계산을 해야 합니까?
누구든지 기능 점수를 계산하도록 훈련받을 수 있기 때문에 자연스러운 질문은 고위급 직원에게 할당할지 여부입니다. 대답은 일반적으로 예입니다. 첫째, 고위급 직원은 일반적으로 기능의 주요 부분이 무시되지 않도록 하기 위해 질문해야 할 사항을 알고 있습니다. 또한 경험이 적은 사람이 간과할 수 있는 문제점을 극복할 수 있습니다.
조직에서 몇 명이나 세어야 합니까?
기능 점수 계산 책임을 할당하는 세 가지(모든 사람, 소그룹 또는 특정된 한사람 ) 가능한 방법이 있습니다:
1) 모든 사람에게 기능점수를 측정하도록 한다면, 모든 사람이 기능 포인트에 익숙해야 정확하게 계산할 수 있는데, 그러나 정확한 결과 도출은 극히 드물다고 보시면 됩니다. 이유는 기능점수 측정이 일상업무가 아님에 따라 6개월 이상 개발 작업을 한 다음 다시 계산한다고 하면 그때까지 그들은 기능점수 규칙을 기억하지 못한 경우가 대다수입니다. 지속적인 재교육은 모든 사람으로부터 정확한 카운트를 얻을 수 있는 유일한 방법이며 이는 비용 효율적이지 않은 경우가 많습니다.
2) 대규모 조직의 경우 기능 점수 계산 및 기타 추정 활동과 관련된 소그룹을 운영하는 것이 이상적입니다. 그룹은 규칙을 최신 상태로 유지하기 위해 충분히 자주 계산해야 합니다. 프로젝트로부터 독립함으로써 그들은 프로젝트에 대해 덜 편향된 피드백을 제공할 수 있을 것입니다. 그룹으로서 그들은 어려운 계산 상황에서 서로 도움을 구할 수 있고 따라서 그들의 계산을 일관되게 유지할 수 있습니다.
3) 한 사람을 조직의 기능 포인트 전문가로 지정하는 것과 관련된 강력한 장점과 단점이 있습니다. 작업량이 적은 경우 한 사람을 할당하는 것이 더 큰 조직에서 그룹을 할당하는 것과 같은 이점이 있습니다. 그러나 기능 점수 전문가는 계산 규칙에 대한 다양한 해석을 반박할 사람이 필요합니다. 이러한 상황에서 IFPUG 로부터 전문가 자격을 획득한 사람의 참여를 필수로 요구합니다. 업계 컨설턴트 중 한 명과의 관계를 유지하는 것이 아마도 필수일 것입니다.
카운트 아웃소싱의 이점은 무엇입니까?
기능 점수 계산의 아웃소싱에는 다른 형태의 아웃소싱과 관련된 모든 이점이 있습니다. 이는 신뢰성, 일관성 및 독립성 문제를 해결할 수 있는 거지요.
언제 기능 점수를 계산할 수 있습니까?
투표와 마찬가지로 사업 발주 전에 자주 집계해야 합니다! 프로젝트가 제공하는 것을 더 빨리 정량화 할수록 더 빨리 제어할 수 있습니다. 전통적으로 많은 실무자들은 제품 설계(또는 외부 설계, 동일한 것의 다른 이름)가 완료될 때까지 기능 점수 계산을 할수 없다고 믿었습니다.
IFPUG 구성원은 개발 수명 주기 초기에 기능 점수를 계산할 수 있는 능력의 중요성을 오랫동안 인식해 왔습니다. IFPUG 4.0에는 요구 사항이 확정되면 기능 점수를 계산할 수 있는 규칙과 지침이 있습니다. 많은 실무자들은 수명 주기에서 더 일찍 기능 점수 크기를 추정할 수 있는 휴리스틱을 사용합니다. 아래 단락에서는 수명 주기의 다양한 지점에서 발생할 수 있는 기능 점수 추정 및 계산에 대해 설명합니다. 모든 사람들이 서로 다른 라이브 사이클을 사용하기 때문에 단계는 관련 결과물에 대한 프로젝트의 진행 측면에서 설명됩니다.
수명 주기가 타당성 조사와 같은 것으로 시작되는 경우 일반적으로 이 시점에서 기능 점수를 계산하는 것은 불가능합니다. 그러나 기능 점수는 현재 코드 라인 또는 노력을 추정하는 데 사용되는 방법과 동일한 기술을 사용하여 추정할 수 있습니다. 유사한 프로젝트가 2,000 기능 점수 였다면 현재 가장 좋은 추측은 이 프로젝트도 2,000 기능 점수라는 것입니다.
요구 사항을 수집하는 동안 기능 점수의 크기 추정치를 지속적으로 세분화할 수 있습니다. 많은 프로젝트에서 논리적 데이터 모델이 개발됩니다. 논리적 데이터 모델에 대한 사람들의 정의는 다양하지만 어느 시점에서 이 모델은 속성이 지정되지 않으며 제3정규형도 아닙니다. 그러나 이 시점에서 분석가는 엔터티를 추가, 변경, 삭제 및 표시하는 프로세스가 필요한 엔터티를 식별하기 시작할 수 있습니다. Yourdon 컨텍스트 다이어그램과 동등한 것이 생성된 경우 사용자 및 외부 시스템과의 상호 작용이 지정됩니다. 이 시점에서 식별된 트랜잭션이 모두 평균 복잡도라고 가정하면 기능 포인트 크기를 적절하게 추정할 수 있습니다. 수명 주기의 이 시점에서도 일반적으로 공정한 정확도로 가치 조정 요인을 예측하는 것이 가능합니다.
비즈니스 요구 사항이 완료되면 응용 프로그램의 기능 점수를 정확하게 계산할 수 있습니다. 이 시점에서 논리적 데이터 모델은 완전히 특성화되어야 합니다. 화면 및 보고서를 포함한 모든 시스템 상호 작용을 식별하고 관련 데이터 항목을 지정해야 합니다. 지금은 화면이나 보고서를 포맷할 필요가 없습니다.
이미 언급한 바와 같이 외부 설계 또는 제품 설계에 따라 정확한 기능 점수를 얻을 수 있습니다. 물론 요구 사항 완료 시 정확한 카운트를 받았어야 합니다. 지금은 요구 사항의 변동성과 프로젝트에 미치는 영향을 고려하기 시작할 때입니다 . 가장 단순한 유형의 요구 사항 변동성은 범위 증가입니다. 요구 사항 종료 시 프로젝트를 1,000 기능 점수로 측정한 다음 제품 설계 후에 1,500 기능 점수를 측정하면 범위 차질(Scope Creep)이 50% 이상입니다.
다른 형태의 요구 사항 변동성은 더 교활할 수 있습니다. 예를 들어 요구 사항 종료 시 기능 점수 1,000점, 프로젝트 설계 종료 시 기능 점수 1,000점을 측정할 수 있습니다. 불행하게도 이러한 이후 기능 점수의 대부분은 요구 사항에서 식별된 기능과 완전히 다른 기능에 대한 것입니다. 어떤 사람들은 이것을 파손이라고 부릅니다. 이름이 무엇이든 추적해야 합니다. 이러한 변화가 수명 주기에서 멀어질수록 이러한 변화에 더 많은 비용이 듭니다. 그러나 기능 점수 크기는 변경되지 않았기 때문에 이러한 변경의 영향은 종종 무시됩니다. 이러한 변화는 향상 기능 점수를 추적해야 합니다. 이러한 방식으로 프로젝트를 재평가해야 할 때 영향을 적절하게 고려할 수 있습니다.
이론상으로는 제품 설계 종료 시점과 승인 테스트 종료 시점 사이에 기능 점수수에 변화가 없어야 합니다. 물론 이론적으로는 이론과 실제 사이에 차이가 없습니다. 실제로는 큰 차이가 있습니다! 이 구현 및 테스트 시간 동안 변경 사항을 적용하는 데 점진적으로 더 많은 비용이 듭니다. 매우 자주 사용자와 프로젝트 관리자는 이 시간 동안 변경 요청, 기능, 비용 및 일정을 교환합니다. 기능 점수는 이러한 협상을 정량화하는 데 사용할 수 있습니다. 그러나 올바르게 사용해야 합니다. 100 기능 포인트 향상을 기능 100 기능 포인트 감소로 바꾸는 것은 현명하지 않습니다. 삭제될 100개의 기능 점수에 이미 소비된 작업도 고려해야 합니다. 다시 말하지만, 강화 기능 포인트를 사용하면 모든 참가자가 이 프로세스를 더 쉽게 수행할 수 있습니다.
프로젝트 종료 시 기능 점수를 업데이트하는 것이 좋습니다. 프로젝트는 향후 프로젝트 추정치를 보다 정확하게 만든다는 생각으로 검토되어야 합니다. 애플리케이션 크기는 필요한 지원 수준을 결정하는 요소이기도 합니다. 사용자 커뮤니티는 애플리케이션과 관련된 비즈니스 가치가 이를 지원하는 데 필요한 노력의 가치가 있는지 여부를 결정해야 합니다.
기능 점수의 사용은 코드 라인의 사용과 어떻게 비교됩니까?
코드라인수는 응용 프로그램 크기를 측정하는 전통적인 방법입니다. 어떤 사람들은 소프트웨어 개발자가 실제로 수행하는 것, 즉 코드 라인을 작성하는 것을 측정하기 때문에 기능 점수에 추가하여 코드 라인을 사용합니다.
일부 전문가들은 코드 라인이 부적절하다고 말합니다. Capers Jones는 "1995년부터 생산성 및 품질 연구를 위한 일련의 코드 메트릭스를 전문적인 과실로 간주할 것"이라고 선언했습니다.
코드 라인 수를 세는 것은 개발자의 관점에서 소프트웨어를 측정하는 것입니다. 기능 점수는 화면, 보고서 및 기타 외부 개체를 기반으로 하므로 이 측정은 사용자의 관점을 취합니다.
코드 라인수가 생산성의 주요 척도인 경우 개발자들은 코드라인수를 많이 생산하려고 하고 재사용 기회를 무시하는 등의 오류를 범하는 단초가 되기도 합니다.
반면에, 기능 점수가 생산성의 주요 척도인 경우 개발자의 기능 생산이 증가하는 경향이 있습니다. 물론 이 기능이 향상된 비즈니스 가치를 제공하는지 여부를 평가하는 것은 사용자의 책임입니다.
코드 라인에는 다른 기술적인 문제가 있습니다. IBM은 BAL, COBOL 및 PL/I가 사용되는 이 기종 개발 환경이 현실화되기 시작했기 때문에 기능 점수를 활용한 측정을 장려했습니다.
이제 거의 모든 프로젝트는 여러 언어를 혼합하여 사용하고 있습니다. 또한 대부분의 최신 개발 프로젝트는 다양한 언어를 사용합니다.
또한 코드 라인이 무엇인지에 대한 표준 정의가 없습니다. 빈 줄이 중요합니까? 댓글이 중요합니까? 데이터 선언이 포함되어 있습니까? 명령문이 여러 줄에 걸쳐 기술하면 어떻게 됩니까? 소프트웨어 엔지니어링 연구소(Software Engineering Institute)와 같은 조직에서는 카운팅을 표준화하기 위한 몇 가지 지침을 발표했지만 IFPUG는 기능 점수에 대해 오너십을 가지고 있는 반면에 코드 라인수에 대한 오너쉽이 어느누구도 가지지 않는다는 점도 향후 소프트웨어 규모측정 방법으로 무엇이 많이 활용될지 판단가능하며, 현재 SW규모측정방법의 국제표준은 기능점수 방법 뿐입니다.
기능 포인트를 객체 지향 개발에 사용할 수 있습니까?
예. 결론적으로 정리하면 응용 프로그램을 측정하는 데 사용할 수 있으며 개체 지향 개발이 사용되지 않은 것과 크기가 동일하다는 것입니다.
이는 애플리케이션의 기능 점수 측정은 애플리케이션 개발에 사용된 기술과 독립적이기 때문입니다. 그러나 객체 지향의 사용은 애플리케이션을 구축하는 프로젝트의 기능 점수에 영향을 미치는 경향이 있습니다.
최소한 객체 지향 개발 기술을 사용하면 개발자가 사전 구축된 Windows 편집 컨트롤 등을 사용할 수 있습니다. 객체 지향이 완전히 수용되면 개발자는 주요 기능을 응용 프로그램에 통합할 수 있습니다. 예를 들어 OLE 자동화를 사용하면 응용 프로그램이 Microsoft Project 버전 4.0의 기능을 완전히 활용할 수 있습니다. 이러한 상황에서 계산하려면 훌륭한 엔지니어링 판단과 경험이 필요합니다.
IFPUG(International Function Point Users Group)는 개체 지향 기술을 사용하여 개발된 애플리케이션의 개수를 보여주는 사례 연구를 참고하시며 도움이 됩니다.
기능 점수를 클라이언트/서버 시스템에 사용할 수 있습니까?
예. 가장 단순한 경우에 사용자는 자신이 중앙 컴퓨터에서 실행되는 프로그램을 사용하고 있는지 또는 네트워크를 통해 다양한 컴퓨터에서 실행 중인 일련의 프로그램을 사용하고 있는지 모를 수 있습니다. 사실, 멋진 클라이언트/서버 세계에서는 존재하는지도 몰랐던 컴퓨터의 오류로 인해 애플리케이션이 이상 종료 (비정상 종료에 도달)할 수 있습니다! 이것은 클라이언트 -서버 시스템이 다른 시스템과 마찬가지로 계산될 수 있다는 강력한 주장을 제시합니다 . 불행하게도 클라이언트/서버는 카운팅 프로세스에 약간의 복잡성을 야기합니다.
기술 인프라의 개발을 설명하는 것은 종종 어려운 일입니다. 기술 인프라는 데이터베이스 관리자, 미들웨어, API 및 개발자가 사용하는 기타 구성 요소로 구성될 수 있습니다. 이 인프라를 설치하는 것은 종종 완전히 별개의 프로젝트입니다. 이 프로젝트와 관련된 기능 점수가 있습니까? 그렇다면 애플리케이션 개발자가 인프라의 사용자인 것처럼 카운트가 수행됩니까? 물론 기업의 비즈니스 사용자 중 일부는 최종 사용자 애플리케이션 개발을 수행할 때 이 인프라와 직접 상호 작용할 수 있습니다. 이로 인해 이전 질문에 대한 답변이 변경됩니까?
우리의 관심을 애플리케이션 프로그램으로 제한할 때에도 클라이언트/서버 시스템 개발 프로젝트의 경계를 식별하는 것은 종종 까다로울 수 있습니다.
그러나, 결론적으로 클라이언트와 서버는 기술적으로 분리된 것으로, 사용자 관점에서는 하나의 경계로 식별하고 있습니다.
GUI 기반 시스템에 기능 포인트를 사용할 수 있습니까?
예. 기능 점수가 처음 개발되었을 때 그래픽 사용자 인터페이스(GUI)가 있는 시스템에는 적용되지 않았습니다. GUI가 있는 시스템은 없었습니다! 이러한 GUI 시스템을 계산하는 방법에 대해 기능점수 측정자간에 어느 정도 의견 차이가 있었습니다.
IFPUG는 Function Point Counting Practices Manual의 릴리스 4.0을 완료했습니다. 여기에는 GUI 기반 시스템 계산에 대한 공식 규칙과 광범위한 예제가 포함되어 있습니다. 그 후 IFPUG는 전체 GUI 기반 시스템의 수를 포함하는 사례 연구를 생성했습니다.
안타깝게도 20년 전까지만 해도 GUI 등 새로운 규칙에 익숙하지 않고, 현재 기술을 반영하도록 과정 자료를 업데이트하지 않은 실무자를 여전히 찾을 수 있습니다.
그러나, 기능 점수 전문가는 반드시 최신 지식과 경험을 가지고 있어야 합니다.
기능 점수는 무엇이며 왜 계산합니까?
70년대 후반에 IBM은 소프트웨어 개발 노력을 추정하기 위해 언어 독립적 접근 방식을 개발할 필요성을 느꼈습니다. 직원 중 한 명인 Allan Albrecht에게 이 접근 방식을 개발하도록 지시했습니다. 결과는 기능 점수 기술이었습니다.
80년대 초반에 기능 점수 기법이 개선되었고 IBM의 GUIDE 조직에서 측정 매뉴얼을 제작했습니다. IFPUG(International Function Point Users Group)는 80년대 후반에 설립되었습니다. 이 조직은 자체 측정 실뮤 매뉴얼을 제작했습니다. 1994년에 IFPUG는 Counting Practices Manual의 릴리스 4.0을 제작했습니다. GUIDE 간행물과 IFPUG 간행물의 각 릴리스에는 Albrecht가 원래 제시한 기술에 대한 개선 사항이 포함되어 있지만 항상 그의 원래 생각과 일치한다고 주장했습니다. 사실, Allan Albrecht 의 최초 출판 이후 거의 20년이 경과한 것을 고려하면 그 내용이 매우 비슷했습니다.
80년대와 90년대 동안 몇몇 사람들은 Albrecht가 수행한 작업을 실질적으로 확장하거나 완전히 대체하기 위한 기능 점수 측정 기술을 제안했습니다. 이들 중 일부는 이 FAQ에서 간략하게 논의될 것입니다. 본 자료의 FAQ는 IFPUG 릴리스 4.0 규칙을 기준으로 개발된 것입니다.
기능 점수는 컴퓨터 응용 프로그램 및 이를 구축하는 프로젝트의 크기를 측정한 것입니다. 크기는 기능적 또는 사용자 관점에서 측정 됩니다. 응용 프로그램을 개발하는 데 사용되는 컴퓨터 언어, 개발 방법론, 기술 또는 프로젝트 팀의 능력과는 별개입니다. Albrecht가 원래 노력을 예측하기 위해 기능 점수 측정 기준이 개발한 것은 단순히 기능 점수가 일반적으로 개발 노력의 주요 동인이라는 사실에 귀결된 것입니다.
기능 점수는 일반적으로 크기가 각각의 기능 규모를 측정하는 중요한 요소이지만 응용 프로그램을 개발하기 위한 노력이나 비즈니스 가치를 완벽하게 측정하는 것은 아닙니다.
이것은 종종 건물 거래에 대한 비유로 설명됩니다. 3,000평방 피트의 집은 일반적으로 6,000평방 피트의 집을 짓는 것보다 더 저렴합니다. 그러나 대리석 욕실 및 타일 바닥과 같은 많은 속성으로 인해 실제로 작은 집이 더 비쌀 수 있습니다. 위치 및 침실 수와 같은 다른 요소도 작은 집을 거주지로 더 가치 있게 만들 수 있습니다.
Bill Hufschmidt 는 항상 기능 점수의 처음 세 글자가 FUN이라고 강조합니다. 기능 점수 계산을 즐기고 그것을 근거로 정당화할 수 있는 사람들은 그렇게 해야 합니다. 다음은 더 어려운 이유입니다.