추정 기법-빠른 가이드

Estimation 입력 데이터가 불완전하거나 불확실하거나 불안정 할 수있는 경우에도 일부 목적으로 사용할 수있는 값인 추정 또는 근사를 찾는 프로세스입니다.

추정은 특정 시스템 또는 제품을 구축하는 데 소요되는 비용, 노력, 자원 및 시간을 결정합니다. 추정은-

• 과거 데이터 / 과거 경험
• 사용 가능한 문서 / 지식
• Assumptions
• 확인 된 위험

소프트웨어 프로젝트 추정의 네 가지 기본 단계는 다음과 같습니다.

• 개발 제품의 크기를 추정하십시오.
• 일인-월 또는 인-시간 단위로 노력을 추정하십시오.
• 달력 달로 일정을 추정하십시오.
• 합의 된 통화로 프로젝트 비용을 추정합니다.

추정에 대한 관찰

• 추정은 프로젝트에서 일회성 작업 일 필요는 없습니다. 그것은 동안 일어날 수 있습니다-

  • 프로젝트 획득.
  • 프로젝트 계획.
  • 필요에 따라 프로젝트 실행.

• 추정 프로세스가 시작되기 전에 프로젝트 범위를 이해해야합니다. 과거 프로젝트 데이터가 있으면 도움이 될 것입니다.

• 프로젝트 지표는 양적 추정을 생성하기위한 역사적 관점과 귀중한 입력을 제공 할 수 있습니다.

• 계획을 수립하려면 기술 관리자와 소프트웨어 팀이 책임과 책임으로 이어지는 초기 약속을해야합니다.

• 과거의 경험이 큰 도움이 될 수 있습니다.

• 최소 두 가지 추정 기법을 사용하여 추정값에 도달하고 결과 값을 조정하십시오. 추정 조정에 대해 알아 보려면 다음 섹션의 분해 기법을 참조하십시오.

• 계획은 반복적이어야하며 시간이 지남에 따라 조정이 가능하고 자세한 내용이 알려 져야합니다.

일반적인 프로젝트 추정 접근법

널리 사용되는 프로젝트 추정 접근법은 다음과 같습니다. Decomposition Technique. 분해 기술은 분할 및 정복 접근 방식을 취합니다. 규모, 노력 및 비용 산정은 프로젝트를 주요 기능 또는 관련 소프트웨어 엔지니어링 활동으로 분할하여 단계적으로 수행됩니다.

Step 1 − 구축 할 소프트웨어의 범위를 이해합니다.

Step 2 − 소프트웨어 크기 추정치를 생성합니다.

• 범위 설명으로 시작하십시오.

• 소프트웨어를 각각 개별적으로 추정 할 수있는 함수로 분해합니다.

• 각 함수의 크기를 계산하십시오.

• 기준 생산성 메트릭에 크기 값을 적용하여 노력과 비용 추정치를 도출하십시오.

• 함수 추정치를 결합하여 전체 프로젝트에 대한 전체 추정치를 생성합니다.

Step 3− 노력과 비용의 추정치를 생성합니다. 프로젝트를 관련 소프트웨어 엔지니어링 활동으로 나누면 노력과 비용 추정치에 도달 할 수 있습니다.

• 프로젝트를 완료하기 위해 수행해야하는 활동의 순서를 식별하십시오.

• 활동을 측정 가능한 작업으로 나눕니다.

• 각 작업을 완료하는 데 필요한 노력 (직접 시간 / 일)을 추정합니다.

• 활동에 대한 추정치를 산출하기 위해 활동 작업의 노력 추정치를 결합합니다.

• 데이터베이스에서 각 활동에 대한 비용 단위 (예 : 비용 / 단위 작업량)를 얻습니다.

• 각 활동에 대한 총 노력과 비용을 계산합니다.

• 각 활동에 대한 노력과 비용 견적을 결합하여 전체 프로젝트에 대한 전체 노력과 비용 견적을 생성합니다.

Step 4− 추정치 조정 : 3 단계의 결과 값을 2 단계에서 얻은 값과 비교합니다. 두 추정치 집합이 모두 일치하면 수치의 신뢰성이 높은 것입니다. 그렇지 않고 광범위하게 다른 추정이 발생하면 다음 여부에 대한 추가 조사를 수행하십시오

• 프로젝트의 범위가 적절하게 이해되지 않았거나 잘못 해석되었습니다.

• 기능 및 / 또는 활동 분석이 정확하지 않습니다.

• 추정 기법에 사용 된 과거 데이터는 응용 프로그램에 부적절하거나 오래되었거나 잘못 적용되었습니다.

Step 5 − 차이의 원인을 확인한 다음 추정치를 조정합니다.

추정 정확도

정확성은 어떤 것이 현실에 얼마나 가까운지를 나타냅니다. 추정치를 생성 할 때마다 모든 사람들은 수치가 현실에 얼마나 가까운 지 알고 싶어합니다. 생성 당시의 데이터를 고려할 때 모든 추정치는 최대한 정확해야합니다. 물론 숫자에 대한 잘못된 확신을 불러 일으키는 방식으로 추정치를 제시하고 싶지는 않습니다.

추정의 정확성에 영향을 미치는 중요한 요소는 다음과 같습니다.

• 모든 추정치 입력 데이터의 정확성입니다.

• 추정 계산의 정확성.

• 모델을 보정하는 데 사용 된 과거 데이터 또는 산업 데이터가 추정하는 프로젝트와 얼마나 일치하는지.

• 조직의 소프트웨어 개발 프로세스에 대한 예측 가능성.

• 제품 요구 사항과 소프트웨어 엔지니어링 노력을 지원하는 환경의 안정성.

• 실제 프로젝트가 신중하게 계획, 모니터링 및 제어되었는지 여부와 예상치 못한 지연을 초래 한 큰 놀라움이 없었는지 여부.

다음은 신뢰할 수있는 추정치를 얻기위한 몇 가지 지침입니다.

• 이미 완료된 유사한 프로젝트를 기준으로 추정합니다.
• 비교적 간단한 분해 기술을 사용하여 프로젝트 비용 및 노력 추정치를 생성합니다.
• 소프트웨어 비용 및 노력 추정을 위해 하나 이상의 경험적 추정 모델을 사용합니다.

이 장의 추정 지침 섹션을 참조하십시오.

정확성을 보장하려면 항상 최소 두 가지 기술을 사용하여 추정하고 결과를 비교하는 것이 좋습니다.

추정 문제

종종 프로젝트 관리자는 크기를 예측하기 위해 일정을 건너 뛰는 예측에 의존합니다. 이는 최고 경영진이나 마케팅 팀이 정한 일정 때문일 수 있습니다. 그러나 이유가 무엇이든 이것이 수행되면 이후 단계에서 범위 변경을 수용 할 일정을 추정하기가 어려울 것입니다.

추정하는 동안 특정 가정을 할 수 있습니다. 일부는 여전히 추정 시트에 가정을 문서화하지 않기 때문에 이러한 모든 가정을 추정 시트에 기록하는 것이 중요합니다.

좋은 추정치조차도 내재 된 가정, 위험 및 불확실성을 가지고 있지만 종종 정확한 것처럼 취급됩니다.

추정치를 표현하는 가장 좋은 방법은 가능한 결과의 범위를 지정하는 것입니다. 예를 들어, 프로젝트가 특정 날짜에 완료되거나 고정 된 번호로 완료 될 것이라고 말하는 대신 5 ~ 7 개월이 소요될 것입니다. 개월. 확정 된 날짜를 지정하는 것과 동일하므로 너무 좁은 범위를 지정하지 않도록주의하십시오.

• 수반되는 확률 값으로 불확실성을 포함 할 수도 있습니다. 예를 들어, 프로젝트가 정해진 날짜 또는 그 이전에 완료 될 확률이 90 %입니다.

• 조직은 정확한 프로젝트 데이터를 수집하지 않습니다. 추정의 정확성은 과거 데이터에 따라 다르기 때문에 문제가 될 수 있습니다.

• 모든 프로젝트에 대해 필요한 기능을 포함하고 품질 출력을 생성 할 수있는 가능한 가장 짧은 일정이 있습니다. 관리 및 / 또는 클라이언트에 의해 일정 제약이있는 경우 제공 할 범위 및 기능에 대해 협상 할 수 있습니다.

• 일정 초과를 방지하기 위해 범위 크립 처리에 대해 클라이언트와 동의합니다.

• 최종 추정치에서 우발 사항을 수용하지 못하면 문제가 발생합니다. 예 : 회의, 조직 행사.

• 리소스 사용률은 80 % 미만으로 간주해야합니다. 이는 자원이 시간의 80 % 동안 만 생산적이기 때문입니다. 80 % 이상의 사용률로 자원을 할당하면 미끄러짐이 발생할 수 있습니다.

추정 지침

프로젝트를 평가하는 동안 다음 지침을 염두에 두어야합니다.

• 평가하는 동안 다른 사람들의 경험을 물어보십시오. 또한 자신의 경험을 작업에 넣으십시오.

• 리소스가 시간의 80 % 동안 만 생산적이라고 가정합니다. 따라서 추정하는 동안 리소스 사용률을 80 % 미만으로 사용하십시오.

• 여러 프로젝트에서 작업하는 리소스는 작업을 전환하는 데 시간이 걸리기 때문에 작업을 완료하는 데 더 오래 걸립니다.

• 예상치에 관리 시간을 포함하십시오.

• 문제 해결, 회의 및 기타 예기치 않은 이벤트에 대비하여 항상 우발적 인 상황에 대비하십시오.

• 적절한 프로젝트 견적을 내기 위해 충분한 시간을 허용하십시오. 급한 추정치는 부정확하고 위험성이 높은 추정치입니다. 대규모 개발 프로젝트의 경우 추정 단계는 실제로 미니 프로젝트로 간주되어야합니다.

• 가능하면 조직의 유사한 과거 프로젝트에서 문서화 된 데이터를 사용하십시오. 가장 정확한 추정치를 얻을 수 있습니다. 조직에서 기록 데이터를 보관하지 않은 경우 지금 수집을 시작하는 것이 좋습니다.

• 작업을 수행 할 사람이 아닌 다른 사람이 준비한 추정치는 정확도가 떨어질 수 있으므로 개발자 기반 추정치를 사용하십시오.

• 여러 사람을 사용하여 여러 가지 추정 기법을 추정하고 사용합니다.

• 추정치를 조정하십시오. 추정치 간의 수렴 또는 산포를 관찰하십시오. Convergence는 좋은 추정치를 얻었다는 것을 의미합니다. Wideband-Delphi 기술은 정확하고 편향되지 않은 추정치를 생성하기위한 목적으로 사람들 그룹을 사용하여 추정치를 수집하고 논의하는 데 사용할 수 있습니다.

• 수명주기 동안 프로젝트를 여러 번 재평가합니다.

ㅏ Function Point(FP)는 정보 시스템 (제품)이 사용자에게 제공하는 비즈니스 기능의 양을 표현하는 측정 단위입니다. FP는 소프트웨어 크기를 측정합니다. 기능적 크기 조정을위한 산업 표준으로 널리 사용됩니다.

FP를 기반으로 한 소프트웨어 사이징을 위해 몇 가지 인정 된 표준 및 / 또는 공개 사양이 존재합니다. 2013 년 현재 다음과 같습니다.

ISO 표준

• COSMIC− ISO / IEC 19761 : 2011 소프트웨어 엔지니어링. 기능적인 크기 측정 방법.

• FiSMA − ISO / IEC 29881 : 2008 정보 기술-소프트웨어 및 시스템 엔지니어링-FiSMA 1.1 기능 크기 측정 방법.

• IFPUG − ISO / IEC 20926 : 2009 소프트웨어 및 시스템 엔지니어링-소프트웨어 측정-IFPUG 기능적 크기 측정 방법.

• Mark-II − ISO / IEC 20968 : 2002 소프트웨어 엔지니어링-Ml II 기능 포인트 분석-계수 실습 매뉴얼.

• NESMA − ISO / IEC 24570 : 2005 소프트웨어 엔지니어링-NESMA 기능 크기 측정 방법 버전 2.1-기능 포인트 분석 적용을위한 정의 및 계산 지침.

자동화 된 기능 포인트에 대한 개체 관리 그룹 사양

개방형 멤버쉽 및 비영리 컴퓨터 산업 표준 컨소시엄 인 OMG (Object Management Group)는 IT 소프트웨어 품질을위한 컨소시엄이 이끄는 AFP (Automated Function Point) 사양을 채택했습니다. IFPUG (International Function Point User Group)의 지침에 따라 FP 계산을 자동화하는 표준을 제공합니다.

Function Point Analysis (FPA) technique소프트웨어 사용자에게 의미있는 용어로 소프트웨어에 포함 된 기능을 수량화합니다. FP는 요구 사항 사양에 따라 개발중인 기능의 수를 고려합니다.

Function Points (FP) Counting국제 기능 포인트 사용자 그룹 (IFPUG)에서 정의한 표준 규칙, 프로세스 및 지침의 적용을받습니다. 이것들은 Counting Practices Manual (CPM)에 게시되어 있습니다.

기능 포인트 분석의 역사

기능 점수의 개념은 1979 년 IBM의 Alan Albrecht에 의해 도입되었습니다. 1984 년 Albrecht는 방법을 개선했습니다. 첫 번째 기능 포인트 지침은 1984 년에 발표되었습니다. 국제 기능 포인트 사용자 그룹 (IFPUG)은 기능 포인트 분석 메트릭 소프트웨어 사용자로 구성된 미국에 기반을 둔 전 세계 조직입니다. 그만큼International Function Point Users Group (IFPUG)1986 년에 설립 된 비영리 회원 관리 조직입니다. IFPUG는 IFPUG의 기능 크기 측정 (FSM) 방법을 적용하기위한 정의, 규칙 및 단계를 지정하는 ISO 표준 20296 : 2009에 정의 된 기능 점수 분석 (FPA)을 소유하고 있습니다. IFPUG는 CPM (Function Point Counting Practices Manual)을 유지합니다. CPM 2.0은 1987 년에 출시되었으며 그 이후로 여러 차례 반복되었습니다. CPM 릴리스 4.3은 2010 년에있었습니다.

ISO 편집 개정판이 통합 된 CPM 릴리스 4.3.1은 2010 년이었습니다. ISO 표준 (IFPUG FSM)-CPM 4.3.1의 일부인 기능적 크기 측정은 제공하는 기능 측면에서 소프트웨어를 측정하는 기술입니다. CPM은 ISO / IEC 14143-1 정보 기술 – 소프트웨어 측정에 따라 국제적으로 승인 된 표준입니다.

기초 과정 (EP)

기본 프로세스는 다음과 같은 기능적 사용자 요구 사항의 가장 작은 단위입니다.

• 사용자에게 의미가 있습니다.
• 완전한 거래를 구성합니다.
• 독립형이며 응용 프로그램의 비즈니스가 일관된 상태로 계산됩니다.

기능

두 가지 유형의 기능이 있습니다-

• 데이터 기능
• 거래 기능

데이터 기능

데이터 함수에는 두 가지 유형이 있습니다.

• 내부 논리 파일
• 외부 인터페이스 파일

데이터 기능은 시스템에 영향을 미치는 내부 및 외부 리소스로 구성됩니다.

Internal Logical Files

ILF (내부 논리 파일)는 응용 프로그램 경계 내에 완전히 상주하는 논리적으로 관련된 데이터 또는 제어 정보의 사용자 식별 가능 그룹입니다. ILF의 주요 목적은 계산되는 애플리케이션의 하나 이상의 기본 프로세스를 통해 유지되는 데이터를 유지하는 것입니다. ILF는 내부적으로 유지 관리되고 논리적 구조가 있으며 파일에 저장된다는 고유 한 의미를 갖습니다. (그림 1 참조)

External Interface Files

EIF (외부 인터페이스 파일)는 참조 목적으로 만 응용 프로그램에서 사용하는 논리적으로 관련된 데이터 또는 제어 정보의 사용자 식별 가능 그룹입니다. 데이터는 완전히 애플리케이션 경계 외부에 있으며 다른 애플리케이션에 의해 ILF에서 유지됩니다. EIF는 외부 적으로 유지되는 고유 한 의미를 가지며 파일에서 데이터를 가져 오려면 인터페이스를 개발해야합니다. (그림 1 참조)

거래 기능

트랜잭션 기능에는 세 가지 유형이 있습니다.

• 외부 입력
• 외부 출력
• 외부 문의

트랜잭션 기능은 사용자, 외부 응용 프로그램 및 측정중인 응용 프로그램간에 교환되는 프로세스로 구성됩니다.

External Inputs

외부 입력 (EI)은 데이터가 경계 외부에서 내부로 애플리케이션으로 "들어가는"트랜잭션 기능입니다. 이 데이터는 애플리케이션 외부로 전달됩니다.

• 데이터는 데이터 입력 화면이나 다른 응용 프로그램에서 가져올 수 있습니다.
• EI는 애플리케이션이 정보를 얻는 방법입니다.
• 데이터는 제어 정보 또는 비즈니스 정보 일 수 있습니다.
• 데이터는 하나 이상의 내부 논리 파일을 유지하는 데 사용될 수 있습니다.
• 데이터가 제어 정보 인 경우 내부 논리 파일을 업데이트 할 필요가 없습니다. (그림 1 참조)

External Outputs

외부 출력 (EO)은 데이터가 시스템에서 "외부로 나오는"트랜잭션 기능입니다. 또한 EO는 ILF를 업데이트 할 수 있습니다. 데이터는 다른 응용 프로그램으로 전송되는 보고서 또는 출력 파일을 생성합니다. (그림 1 참조)

External Inquiries

외부 조회 (EQ)는 데이터 검색을 초래하는 입력 및 출력 구성 요소가 모두있는 트랜잭션 기능입니다. (그림 1 참조)

RET, DET, FTR의 정의

레코드 요소 유형

RET (레코드 요소 유형)는 ILF 또는 EIF 내에서 사용자가 식별 할 수있는 가장 큰 요소 하위 그룹입니다. 데이터를 식별하는 데 도움이되도록 데이터의 논리적 그룹을 살펴 보는 것이 가장 좋습니다.

데이터 요소 유형

데이터 요소 유형 (DET)은 FTR 내의 데이터 하위 그룹입니다. 고유하고 사용자 식별이 가능합니다.

참조 된 파일 유형

참조 된 파일 유형 (FTR)은 참조되는 EI, EO 또는 EQ 내에서 가장 큰 사용자 식별 가능 하위 그룹입니다.

트랜잭션 함수 EI, EO, EQ는 다음 계산 규칙을 ​​포함하는 FTR 및 DET를 계산하여 측정됩니다. 마찬가지로 데이터 함수 ILF 및 EIF는 다음 계산 규칙을 ​​포함하는 DET 및 RET를 계산하여 측정됩니다. 트랜잭션 기능 및 데이터 기능의 측정 값은 기능적 크기 또는 기능 포인트를 산출하는 FP 계산에 사용됩니다.

FP 계산 프로세스는 다음 단계를 포함합니다-

• Step 1 − 카운트 유형을 결정합니다.

• Step 2 − 개수의 경계를 결정합니다.

• Step 3 − 사용자가 요구하는 각 기본 프로세스 (EP)를 식별합니다.

• Step 4 − 고유 한 EP를 결정합니다.

• Step 5 − 데이터 기능을 측정합니다.

• Step 6 − 트랜잭션 기능을 측정합니다.

• Step 7 − 기능 크기 (조정되지 않은 기능 점수 수)를 계산합니다.

• Step 8 − 값 조정 계수 (VAF)를 결정합니다.

• Step 9 − 조정 된 기능 점수를 계산합니다.

Note− 일반 시스템 특성 (GSC)은 CPM 4.3.1에서 선택 사항이며 부록으로 이동되었습니다. 따라서 8 단계와 9 단계를 건너 뛸 수 있습니다.

1 단계 : 개수 유형 결정

기능 점수 계산에는 세 가지 유형이 있습니다.

• 개발 기능 점수
• 애플리케이션 기능 점수
• 강화 기능 점수

개발 기능 점수

기능 포인트는 요구 사항에서 구현 단계까지 개발 프로젝트의 모든 단계에서 계산할 수 있습니다. 이러한 유형의 카운트는 새로운 개발 작업과 관련이 있으며 변환 노력을 지원하는 임시 솔루션으로 필요할 수있는 프로토 타입을 포함 할 수 있습니다. 이러한 유형의 카운트를 기준 기능 포인트 카운트라고합니다.

애플리케이션 기능 점수

응용 프로그램 수는 제공된 기능 포인트로 계산되며 모든 변환 노력 (프로토 타입 또는 임시 솔루션) 및 존재했을 수있는 기존 기능은 제외됩니다.

강화 기능 점수

생산 후 소프트웨어를 변경하면 개선 사항으로 간주됩니다. 이러한 향상 프로젝트의 크기를 조정하기 위해 기능 포인트 수는 애플리케이션에서 추가, 변경 또는 삭제됩니다.

2 단계 : 개수의 경계 결정

경계는 측정중인 애플리케이션과 외부 애플리케이션 또는 사용자 도메인 사이의 경계를 나타냅니다. (그림 1 참조)

경계를 결정하려면 이해하십시오-

• 기능 점수 계산의 목적
• 측정중인 애플리케이션의 범위
• 어떤 애플리케이션이 어떤 데이터를 유지하는 방법과 애플리케이션
• 애플리케이션을 지원하는 비즈니스 영역

3 단계 : 사용자에게 필요한 각 기본 프로세스 식별

기능적 사용자 요구 사항을 다음 기준을 모두 충족하는 최소 활동 단위로 구성 및 / 또는 분해합니다.

• 사용자에게 의미가 있습니다.
• 완전한 거래를 구성합니다.
• 독립형입니다.
• 일관된 상태로 계산되는 애플리케이션의 비즈니스를 유지합니다.

예를 들어, 기능적 사용자 요구 사항- "직원 정보 유지"는 직원 추가, 직원 변경, 직원 삭제 및 직원에 대한 문의와 같은 더 작은 활동으로 분해 될 수 있습니다.

이렇게 식별 된 각 활동 단위는 기본 프로세스 (EP)입니다.

4 단계 : 고유 한 기본 프로세스 결정

이미 식별 된 두 개의 EP를 비교하여 다음과 같은 경우 하나의 EP (동일한 EP)로 계산합니다.

• 동일한 DET 세트가 필요합니다.
• 동일한 FTR 세트가 필요합니다.
• EP를 완료하려면 동일한 처리 로직 세트가 필요합니다.

여러 형태의 처리 로직이있는 EP를 여러 EPS로 분할하지 마십시오.

예를 들어 '직원 추가'를 EP로 식별 한 경우 직원이 부양 가족이있을 수도 있고 없을 수도 있다는 사실을 고려하여 두 개의 EP로 나누어서는 안됩니다. EP는 여전히 '직원 추가'이며 부양 가족을 설명하기 위해 처리 논리 및 DET에 변형이 있습니다.

5 단계 : 데이터 함수 측정

각 데이터 함수를 ILF 또는 EIF로 분류합니다.

데이터 함수는-

• ILF (내부 논리 파일) (측정중인 응용 프로그램에서 유지 관리하는 경우)

• 외부 인터페이스 파일 (EIF) (참조되지만 측정중인 응용 프로그램에서 유지 관리되지 않는 경우).

ILF 및 EIF에는 비즈니스 데이터, 제어 데이터 및 규칙 기반 데이터가 포함될 수 있습니다. 예를 들어, 전화 교환은 비즈니스 데이터, 규칙 데이터 및 제어 데이터의 세 가지 유형으로 구성됩니다. 비즈니스 데이터는 실제 호출입니다. 규칙 데이터는 호출이 네트워크를 통해 라우팅되는 방법이고 제어 데이터는 스위치가 서로 통신하는 방법입니다.

ILF 및 EIF 계산에 대한 다음 문서를 고려하십시오.

• 제안 된 시스템의 목적 및 제약.
• 현재 시스템에 관한 문서 (해당 시스템이있는 경우).
• 사용자가 인식 한 목표, 문제 및 요구 사항에 대한 문서화.
• 데이터 모델.

5.1 단계 : 각 데이터 함수에 대한 DET 계산

ILF / EIF에 대한 DET를 계산하려면 다음 규칙을 적용하십시오.

• EP 실행을 통해 ILF 또는 EIF에서 유지되거나 검색된 고유 사용자 식별 가능, 반복되지 않는 필드 각각에 대해 DET를 계산합니다.

• 둘 이상의 응용 프로그램이 동일한 데이터 기능을 유지 및 / 또는 참조 할 때 측정되는 응용 프로그램에서 사용중인 DET 만 계산합니다.

• 사용자가 다른 ILF 또는 EIF와의 관계를 설정하는 데 필요한 각 속성에 대해 DET를 계산합니다.

• 관련 속성을 검토하여 그룹화되어 단일 DET로 계산되는지 또는 여러 DET로 계산되는지 여부를 결정합니다. 그룹화는 EP가 응용 프로그램 내에서 속성을 사용하는 방법에 따라 다릅니다.

5.2 단계 : 각 데이터 함수에 대한 RET 계산

ILF / EIF에 대한 RET를 계산하려면 다음 규칙을 적용하십시오.

• 각 데이터 함수에 대해 하나의 RET를 계산합니다.
• DET의 다음 추가 논리적 하위 그룹 각각에 대해 하나의 추가 RET를 계산합니다.
  • 키가 아닌 속성이있는 연관 엔티티.
  • 하위 유형 (첫 번째 하위 유형 제외).
  • 필수 1 : 1 이외의 관계에있는 귀속 엔티티.

5.3 단계 : 각 데이터 함수에 대한 기능 복잡성 결정

RETS	데이터 요소 유형 (DET)
	1-19	20-50	>50
1	엘	엘	ㅏ
2에서 5	엘	ㅏ	H
> 5	ㅏ	H	H

기능적 복잡성 : L = 낮음; A = 평균; H = 높음

5.4 단계 : 각 데이터 함수의 기능적 크기 측정

기능적 복잡성	ILF에 대한 FP 수	EIF에 대한 FP 수
낮은	7	5
평균	10	7
높은	15	10

6 단계 : 트랜잭션 함수 측정

다음은 트랜잭션 기능을 측정하기 위해 필요한 단계입니다.

6.1 단계 : 각 트랜잭션 기능 분류

트랜잭션 기능은 외부 입력, 외부 출력 또는 외부 조회로 분류되어야합니다.

외부 입력

외부 입력 (EI)은 경계 외부에서 오는 데이터 또는 제어 정보를 처리하는 기본 프로세스입니다. EI의 주요 목적은 하나 이상의 ILF를 유지하고 /하거나 시스템의 동작을 변경하는 것입니다.

다음 규칙을 모두 적용해야합니다.

• 데이터 또는 제어 정보는 애플리케이션 경계 외부에서 수신됩니다.

• 경계에 입력되는 데이터가 시스템 동작을 변경하는 제어 정보가 아닌 경우 적어도 하나의 ILF가 유지됩니다.

• 식별 된 EP의 경우 세 가지 진술 중 하나가 적용되어야합니다.

  • 처리 논리는 응용 프로그램에 대해 다른 EI에서 수행하는 처리 논리와 다릅니다.

  • 식별 된 데이터 요소 세트는 애플리케이션의 다른 EI에 대해 식별 된 세트와 다릅니다.

  • 참조 된 ILF 또는 EIF는 애플리케이션의 다른 EI가 참조하는 파일과 다릅니다.

외부 출력

외부 출력 (EO)은 애플리케이션 경계 외부로 데이터 또는 제어 정보를 보내는 기본 프로세스입니다. EO에는 외부 문의 이상의 추가 처리가 포함됩니다.

EO의 주요 목적은 데이터 또는 제어 정보 검색 이외의 처리 로직을 통해 사용자에게 정보를 제공하는 것입니다.

처리 로직은-

• 하나 이상의 수학 공식 또는 계산을 포함합니다.
• 파생 데이터를 만듭니다.
• 하나 이상의 ILF를 유지합니다.
• 시스템의 동작을 변경합니다.

다음 규칙을 모두 적용해야합니다.

• 응용 프로그램의 경계 외부로 데이터 또는 제어 정보를 보냅니다.
• 식별 된 EP의 경우 세 가지 진술 중 하나가 적용되어야합니다.
  • 처리 논리는 응용 프로그램에 대해 다른 EO가 수행하는 처리 논리와 다릅니다.
  • 식별 된 데이터 요소 세트는 애플리케이션의 다른 EO와 다릅니다.
  • 참조 된 ILF 또는 EIF는 애플리케이션의 다른 EO가 참조하는 파일과 다릅니다.

또한 다음 규칙 중 하나가 적용되어야합니다.

• 처리 논리에는 하나 이상의 수학 공식 또는 계산이 포함됩니다.
• 처리 로직은 적어도 하나의 ILF를 유지합니다.
• 처리 논리는 시스템의 동작을 변경합니다.

외부 문의

외부 조회 (EQ)는 데이터 또는 제어 정보를 경계 외부로 보내는 기본 프로세스입니다. EQ의 주요 목적은 데이터 검색 또는 제어 정보를 통해 사용자에게 정보를 제공하는 것입니다.

처리 논리에는 수학 공식이나 계산이 포함되지 않으며 파생 데이터가 생성되지 않습니다. 처리 중에는 ILF가 유지되지 않으며 시스템 동작도 변경되지 않습니다.

다음 규칙을 모두 적용해야합니다.

• 응용 프로그램의 경계 외부로 데이터 또는 제어 정보를 보냅니다.
• 식별 된 EP의 경우 세 가지 진술 중 하나가 적용되어야합니다.
  • 처리 논리는 응용 프로그램의 다른 EQ에서 수행하는 처리 논리와 다릅니다.
  • 식별 된 데이터 요소 세트는 애플리케이션의 다른 EQ와 다릅니다.
  • 참조 된 ILF 또는 EIF는 응용 프로그램의 다른 EQ에서 참조하는 파일과 다릅니다.

또한 다음 규칙이 모두 적용되어야합니다.

• 처리 로직은 ILF 또는 EIF에서 데이터 또는 제어 정보를 검색합니다.
• 처리 논리에는 수학 공식이나 계산이 포함되어 있지 않습니다.
• 처리 논리는 시스템의 동작을 변경하지 않습니다.
• 처리 로직은 ILF를 유지하지 않습니다.

6.2 단계 : 각 트랜잭션 함수에 대한 DET 계산

다음 규칙을 적용하여 EI에 대한 DET 계산-

• 경계를 통과하는 (들어가거나 나가는) 모든 것을 검토합니다.

• 트랜잭션 기능을 처리하는 동안 경계를 넘나 드는 (들어가거나 나가는) 고유 한 사용자 식별 가능하고 반복되지 않는 속성 각각에 대해 DET 하나를 계산합니다.

• 여러 메시지가있는 경우에도 애플리케이션 응답 메시지를 보내는 기능에 대해 트랜잭션 함수 당 하나의 DET 만 계산합니다.

• 여러 가지 방법이 있더라도 작업을 시작하는 기능에 대해 트랜잭션 기능 당 하나의 DET 만 계산합니다.

• 다음 항목을 DET로 계산하지 마십시오-

  • 트랜잭션 함수에 의해 경계 내에서 생성되고 경계를 벗어나지 않고 ILF에 저장되는 속성.

  • 보고서 제목, 화면 또는 패널 식별자, 열 머리글 및 속성 제목과 같은 리터럴.

  • 날짜 및 시간 속성과 같은 애플리케이션 생성 스탬프.

  • 페이징 변수, 페이지 번호 및 위치 정보 (예 : '211 행 중 37 ~ 54 행').

  • "이전", "다음", "첫 번째", "마지막"및 그에 상응하는 그래픽을 사용하여 목록 내에서 탐색하는 기능과 같은 탐색 도구.

다음 규칙을 적용하여 EO / EQ에 대한 DET를 계산합니다.

• 경계를 통과하는 (들어가거나 나가는) 모든 것을 검토합니다.

• 트랜잭션 기능을 처리하는 동안 경계를 넘나 드는 (들어가거나 나가는) 고유 한 사용자 식별 가능하고 반복되지 않는 속성 각각에 대해 DET 하나를 계산합니다.

• 여러 메시지가있는 경우에도 애플리케이션 응답 메시지를 보내는 기능에 대해 트랜잭션 함수 당 하나의 DET 만 계산합니다.

• 여러 가지 방법이 있더라도 작업을 시작하는 기능에 대해 트랜잭션 기능 당 하나의 DET 만 계산합니다.

• 다음 항목을 DET로 계산하지 마십시오-

  • 경계를 넘지 않고 경계 내에서 생성 된 속성입니다.

  • 보고서 제목, 화면 또는 패널 식별자, 열 머리글 및 속성 제목과 같은 리터럴.

  • 날짜 및 시간 속성과 같은 애플리케이션 생성 스탬프.

  • 페이징 변수, 페이지 번호 및 위치 정보 (예 : '211 행 중 37 ~ 54 행').

  • "이전", "다음", "첫 번째", "마지막"및 그에 상응하는 그래픽을 사용하여 목록 내에서 탐색하는 기능과 같은 탐색 도구.

6.3 단계 : 각 트랜잭션 함수에 대한 FTR 계산

다음 규칙을 적용하여 EI에 대한 FTR을 계산합니다.

• 유지되는 각 ILF에 대해 FTR을 계산합니다.
• EI 처리 중에 읽은 각 ILF 또는 EIF에 대한 FTR을 계산합니다.
• 유지되고 읽히는 각 ILF에 대해 하나의 FTR 만 계산합니다.

EO / EQ에 대한 FTR을 계산하려면 다음 규칙을 적용하십시오.

• EP 처리 중에 읽은 각 ILF 또는 EIF에 대해 FTR을 계산합니다.

또한 EO에 대한 FTR을 계산하려면 다음 규칙을 적용하십시오.

• EP 처리 중에 유지되는 각 ILF에 대한 FTR을 계산합니다.
• EP가 유지하고 읽는 각 ILF에 대해 하나의 FTR 만 계산합니다.

단계 6.4 : 각 트랜잭션 함수에 대한 기능 복잡성 결정

FTR	데이터 요소 유형 (DET)
	1-4	5-15	>=16
0-1	엘	엘	ㅏ
2	엘	ㅏ	H
> = 3	ㅏ	H	H

기능적 복잡성 : L = 낮음; A = 평균; H = 높음

EQ가 최소 1 FTR을 가져야한다는 점을 제외하고 각 EO / EQ의 기능적 복잡성을 결정합니다.

EQ에는 최소 1 FTR이 있어야합니다. FTR	데이터 요소 유형 (DET)
	1-4	5-15	> = 16
0-1	엘	엘	ㅏ
2	엘	ㅏ	H
> = 3	ㅏ	H	H

기능적 복잡성 : L = 낮음; A = 평균; H = 높음

6.5 단계 : 각 트랜잭션 함수의 기능 크기 측정

기능 복잡성에서 각 EI의 기능 크기를 측정합니다.

복잡성	FP 수
낮은	삼
평균	4
높은	6

기능적 복잡성에서 각 EO / EQ의 기능적 크기를 측정합니다.

복잡성	EO에 대한 FP 수	EQ 용 FP 수
낮은	4	삼
평균	5	4
높은	6	6

7 단계 : 기능 크기 계산 (조정되지 않은 기능 점수 수)

기능적 크기를 계산하려면 아래 단계를 따라야합니다.

7.1 단계

1 단계에서 찾은 것을 기억하십시오. 개수 유형을 결정하십시오.

7.2 단계

유형에 따라 기능 크기 또는 기능 포인트 수를 계산합니다.

• 개발 기능 점수는 7.3 단계로 이동하십시오.
• 애플리케이션 기능 점수는 7.4 단계로 이동하십시오.
• 향상 기능 점수는 7.5 단계로 이동합니다.

7.3 단계

개발 기능 점수는 기능의 두 가지 구성 요소로 구성됩니다.

• 프로젝트에 대한 사용자 요구 사항에 포함 된 애플리케이션 기능.

• 프로젝트에 대한 사용자 요구 사항에 포함 된 변환 기능. 변환 기능은 설치시에만 제공되는 기능으로 구성되어 데이터를 변환하거나 특수 변환 보고서와 같은 기타 사용자 지정 변환 요구 사항을 제공합니다. 예를 들어 기존 애플리케이션을 새 시스템으로 대체 할 수 있습니다.

DFP = ADD + CFP

어디,

DFP = 개발 기능 점수

ADD = 개발 프로젝트에서 사용자에게 제공하는 기능의 크기

CFP = 변환 기능의 크기

ADD = FP 개수 (ILF) + FP 개수 (EIF) + FP 개수 (EI) + FP 개수 (EO) + FP 개수 (EQ)

CFP = FP 개수 (ILF) + FP 개수 (EIF) + FP 개수 (EI) + FP 개수 (EO) + FP 개수 (EQ)

7.4 단계

응용 프로그램 기능 점수 계산

AFP = ADD

어디,

AFP = 애플리케이션 기능 점수

ADD = 개발 프로젝트에서 사용자에게 제공하는 기능의 크기 (변환 기능의 크기 제외) 또는 애플리케이션이 계산 될 때마다 존재하는 기능.

ADD = FP 개수 (ILF) + FP 개수 (EIF) + FP 개수 (EI) + FP 개수 (EO) + FP 개수 (EQ)

7.5 단계

향상 기능 포인트 카운트는 다음 네 가지 기능 구성 요소를 고려합니다.

• 응용 프로그램에 추가되는 기능입니다.
• 응용 프로그램에서 수정 된 기능.
• 변환 기능.
• 응용 프로그램에서 삭제 된 기능입니다.

EFP = ADD + CHGA + CFP + DEL

어디,

EFP = 강화 기능 점수

ADD = 개선 프로젝트에 의해 추가되는 기능의 크기

CHGA = 개선 프로젝트에 의해 변경되는 기능의 크기

CFP = 변환 기능의 크기

DEL = 향상 프로젝트에 의해 삭제되는 기능의 크기

ADD = FP 개수 (ILF) + FP 개수 (EIF) + FP 개수 (EI) + FP 개수 (EO) + FP 개수 (EQ)

CHGA = FP 개수 (ILF) + FP 개수 (EIF) + FP 개수 (EI) + FP 개수 (EO) + FP 개수 (EQ)

CFP = FP 개수 (ILF) + FP 개수 (EIF) + FP 개수 (EI) + FP 개수 (EO) + FP 개수 (EQ)

DEL = FP 개수 (ILF) + FP 개수 (EIF) + FP 개수 (EI) + FP 개수 (EO) + FP 개수 (EQ)

8 단계 : 값 조정 계수 결정

GSC는 CPM 4.3.1에서 선택 사항이며 부록으로 이동했습니다. 따라서 8 단계와 9 단계를 건너 뛸 수 있습니다.

VAF (Value Adjustment Factor)는 계산되는 애플리케이션의 일반 기능을 평가하는 14 개의 GSC를 기반으로합니다. GSC는 기술과 무관 한 사용자 비즈니스 제약입니다. 각 특성에는 영향의 정도를 결정하는 관련 설명이 있습니다.

일반 시스템 특성	간단한 설명
데이터 통신	애플리케이션 또는 시스템과의 정보 전송 또는 교환을 지원하기 위해 얼마나 많은 통신 시설이 있습니까?
분산 데이터 처리	분산 데이터 및 처리 기능은 어떻게 처리됩니까?
공연	사용자에게 응답 시간 또는 처리량이 필요 했습니까?
많이 사용되는 구성	애플리케이션이 실행될 현재 하드웨어 플랫폼은 얼마나 많이 사용됩니까?
거래 율	거래는 매일, 매주, 매월 등 얼마나 자주 실행됩니까?
온라인 데이터 입력	온라인으로 입력되는 정보의 비율은 얼마입니까?
최종 사용자 효율성	최종 사용자의 효율성을 위해 애플리케이션이 설계 되었습니까?
온라인 업데이트	온라인 거래로 얼마나 많은 ILF가 업데이트됩니까?
복잡한 처리	응용 프로그램에 광범위한 논리 또는 수학적 처리가 있습니까?
재사용 성	응용 프로그램이 한 명 또는 여러 사용자의 요구를 충족하도록 개발 되었습니까?
설치 용이성	변환 및 설치가 얼마나 어렵습니까?
운영 용이성	시작, 백업 및 복구 절차가 얼마나 효과적이고 / 또는 자동화되어 있습니까?
여러 사이트	응용 프로그램이 여러 조직의 여러 사이트에 설치되도록 특별히 설계, 개발 및 지원 되었습니까?
변화 촉진	변경을 용이하게하기 위해 응용 프로그램이 특별히 설계, 개발 및 지원 되었습니까?

영향 범위는 영향 없음에서 강한 영향까지 0에서 5까지의 범위입니다.

평가	영향력의 정도
0	존재하지 않거나 영향이 없음
1	부수적 영향
2	적당한 영향
삼	평균 영향력
4	중대한 영향
5	전체적으로 강력한 영향력

14 개의 GSC 각각에 대한 영향의 정도를 결정합니다.

이렇게 얻은 14 개의 GSC 값의 합계를 총 영향도 (TDI)라고합니다.

TDI = ∑¹⁴ Degrees of Influence

다음으로 VAF (Value Adjustment Factor)를 다음과 같이 계산합니다.

VAF = (TDI × 0.01) + 0.65

각 GSC는 0에서 5까지, TDI는 (0 × 14)에서 (5 × 14)까지, 즉 0 (모든 GSC가 낮은 경우)에서 70 (모든 GSC가 높은 경우), 즉 0 ≤ TDI ≤ 70까지 다양 할 수 있습니다. 따라서 VAF는 0.65 (모든 GSC가 낮은 경우)에서 1.35 (모든 GSC가 높은 경우), 즉 0.65 ≤ VAF ≤ 1.35 범위에서 다양 할 수 있습니다.

9 단계 : 조정 된 기능 점수 계산

VAF (V4.3.1 이전의 CPM 버전)를 사용하는 FPA 접근 방식에 따라 이는 다음에 의해 결정됩니다.

Adjusted FP Count = Unadjusted FP Count × VAF

여기서 조정되지 않은 FP 수는 7 단계에서 계산 한 기능 크기입니다.

VAF가 0.65에서 1.35까지 다양하기 때문에 VAF는 최종 조정 된 FP 수에 ± 35 %의 영향을 미칩니다.

기능 포인트의 이점

기능 포인트가 유용합니다-

• 문제의 크기 대신 솔루션의 크기를 측정합니다.

• 요구 사항은 기능 점수 계산에 필요한 유일한 것입니다.

• 기술과 무관하기 때문입니다.

• 프로그래밍 언어와 무관하기 때문입니다.

• 테스트 프로젝트를 추정합니다.

• 전체 프로젝트 비용, 일정 및 노력을 추정합니다.

• 계약 협상에서 비즈니스 그룹과의보다 쉬운 커뮤니케이션 방법을 제공합니다.

• 소프트웨어 기능의 실제 사용, 인터페이스 및 목적에 대한 값을 정량화하고 할당합니다.

• 시간, 비용, 인원수, 기간 및 기타 애플리케이션 메트릭과 같은 다른 메트릭으로 비율을 생성합니다.

FP 저장소

ISBSG (International Software Benchmarking Standards Group)는 IT 데이터를위한 두 개의 저장소를 확장하고 유지합니다.

• 개발 및 향상 프로젝트
• 유지 관리 및 지원 응용 프로그램

개발 및 향상 프로젝트 저장소에는 6,000 개 이상의 프로젝트가 있습니다.

데이터는 Microsoft Excel 형식으로 제공되므로 원하는 추가 분석을 더 쉽게 수행하거나 다른 목적으로 데이터를 사용할 수도 있습니다.

ISBSG 저장소 라이센스는 다음에서 구입할 수 있습니다. http://www.isbsg.com/

ISBSG는 할인 코드“IFPUGMembers”를 사용하면 온라인 구매시 IFPUG 회원에게 10 % 할인을 제공합니다.

ISBSG 소프트웨어 프로젝트 데이터 릴리스 업데이트는 다음에서 찾을 수 있습니다. http://www.ifpug.org/isbsg/

COSMIC와 IFPUG는 협력하여 소프트웨어 비 기능 및 프로젝트 요구 사항에 대한 용어집을 작성했습니다. -cosmic-sizing.org 에서 다운로드 할 수 있습니다.

ㅏ Use-Case 사용자가 목표를 달성 할 수 있도록하는 사용자와 시스템 간의 일련의 관련 상호 작용입니다.

Use-Cases는 시스템의 기능 요구 사항을 캡처하는 방법입니다. 시스템 사용자를 '배우'라고합니다. Use-Cases는 기본적으로 텍스트 형식입니다.

사용 사례 포인트 – 정의

Use-Case Points (UCP)사용 사례로 소프트웨어 크기를 측정하는 데 사용되는 소프트웨어 추정 기술입니다. UCP의 개념은 FP와 유사합니다.

프로젝트의 UCP 수는 다음을 기반으로합니다.

• 시스템에서 사용 사례의 수와 복잡성.
• 시스템에있는 액터의 수와 복잡성.

  • 유스 케이스로 작성되지 않은 다양한 비 기능적 요구 사항 (예 : 이식성, 성능, 유지 보수성).

  • 프로젝트가 개발 될 환경 (예 : 언어, 팀의 동기 등)

UCP로 추정하려면 모든 사용 사례를 목표와 거의 동일한 수준으로 작성하여 동일한 세부 정보를 제공해야합니다. 따라서 예측하기 전에 프로젝트 팀은 정의 된 목표와 세부 수준에서 사용 사례를 작성했는지 확인해야합니다. 유스 케이스는 일반적으로 단일 세션 내에서 완료되며 목표를 달성 한 후 사용자는 다른 활동으로 이동할 수 있습니다.

사용 사례 포인트의 역사

Use-Case Point 추정 방법은 1993 년 Gustav Karner에 의해 도입되었습니다.이 작업은 나중에 IBM에 합병 된 Rational Software에서 라이센스를 받았습니다.

사용 사례 포인트 계산 프로세스

사용 사례 포인트 계산 프로세스에는 다음 단계가 있습니다.

• 조정되지 않은 UCP 계산
• 기술적 복잡성에 맞게 조정
• 환경 복잡성에 대한 조정
• 조정 된 UCP 계산

1 단계 : 조정되지 않은 사용 사례 포인트를 계산합니다.

다음 단계에 따라 조정되지 않은 사용 사례 포인트를 먼저 계산합니다.

• 조정되지 않은 사용 사례 무게 결정
• 조정되지 않은 액터 가중치 결정
• 조정되지 않은 사용 사례 포인트 계산

Step 1.1 − 조정되지 않은 사용 사례 무게를 결정합니다.

Step 1.1.1 − 각 사용 사례에서 거래 수를 찾습니다.

Use-Cases가 User Goal Levels로 작성된 경우 트랜잭션은 Use-Case의 단계와 동일합니다. Use-Case의 단계를 계산하여 트랜잭션 수를 찾으십시오.

Step 1.1.2− 각 Use-Case를 Use-Case의 트랜잭션 수에 따라 Simple, Average 또는 Complex로 분류합니다. 또한 다음 표와 같이 Use-Case Weight를 할당합니다.

사용 사례 복잡성	거래 수	사용 사례 무게
단순한	≤3	5
평균	4에서 7	10
복잡한	> 7	15

Step 1.1.3− 각 사용 사례에 대해 반복하고 모든 사용 사례 가중치를 가져옵니다. 조정되지 않은 사용 사례 가중치 (UUCW)는 모든 사용 사례 가중치의 합계입니다.

Step 1.1.4 − 다음 표를 사용하여 조정되지 않은 사용 사례 가중치 (UUCW) 찾기 −

사용 사례 복잡성	사용 사례 무게	사용 사례 수	생성물
단순한	5	NSUC	5 × NSUC
평균	10	NAUC	10 × NAUC
복잡한	15	NCUC	15 × NCUC
Unadjusted Use-Case Weight (UUCW)			5 × NSUC + 10 × NAUC + 15 × NCUC

어디,

NSUC는 아니오입니다. 단순한 사용 사례의.

NAUC는 아니오입니다. 평균 사용 사례의.

NCUC는 아니오입니다. 복잡한 사용 사례의.

Step 1.2 − 조정되지 않은 액터 가중치를 결정합니다.

유스 케이스의 액터는 사람, 다른 프로그램 등이 될 수 있습니다. 정의 된 API가있는 시스템과 같은 일부 액터는 매우 단순한 요구 사항을 가지고 있으며 유스 케이스의 복잡성을 약간만 증가시킵니다.

프로토콜을 통해 상호 작용하는 시스템과 같은 일부 행위자는 더 많은 요구를 가지고 있으며 Use-Case의 복잡성을 어느 정도 증가시킵니다.

GUI를 통해 상호 작용하는 사용자와 같은 다른 행위자는 사용 사례의 복잡성에 상당한 영향을 미칩니다. 이러한 차이를 기반으로 액터를 단순, 평균 및 복합으로 분류 할 수 있습니다.

Step 1.2.1 − 액터를 단순, 평균, 복합으로 분류하고 다음 표와 같이 액터 가중치를 할당합니다 −

배우 복잡성	예	배우 무게
단순한	정의 된 API가있는 시스템	1
평균	프로토콜을 통해 상호 작용하는 시스템	2
복잡한	GUI를 통해 상호 작용하는 사용자	삼

Step 1.2.2-각 액터에 대해 반복하고 모든 액터 가중치를 얻습니다. 조정되지 않은 액터 가중치 (UAW)는 모든 액터 가중치의 합계입니다.

Step 1.2.3 − 다음 표를 사용하여 조정되지 않은 액터 가중치 (UAW) 찾기 −

배우 복잡성	배우 무게	액터 수	생성물
단순한	1	NSA	NSA 1 개
평균	2	NAA	2 × NAA
복잡한	삼	NCA	3 × NCA
Unadjusted Actor Weight (UAW)			NSA 1 개 + NAA 2 개 + NCA 3 개

어디,

NSA는 아니오입니다. 단순한 액터의.

NAA는 아니오입니다. 평균 배우의.

NCA는 아니오입니다. 복잡한 배우의.

Step 1.3 − 조정되지 않은 사용 사례 포인트를 계산합니다.

조정되지 않은 사용 사례 가중치 (UUCW) 및 조정되지 않은 배우 가중치 (UAW)는 함께 조정되지 않은 사용 사례 포인트라고하는 시스템의 조정되지 않은 크기를 제공합니다.

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

다음 단계는 기술 복잡성 및 환경 복잡성에 대해 조정되지 않은 사용 사례 포인트 (UUCP)를 조정하는 것입니다.

2 단계 : 기술 복잡성 조정

Step 2.1 − 프로젝트의 기술적 복잡성이 사용 사례 포인트에 미치는 영향에 기여하는 13 가지 요소와 다음 표에 나와있는 해당 가중치를 고려합니다.

인자	기술	무게
T1	분산 시스템	2.0
T2	응답 시간 또는 처리량 성능 목표	1.0
T3	최종 사용자 효율성	1.0
T4	복잡한 내부 처리	1.0
T5	코드는 재사용 가능해야합니다.	1.0
T6	간편한 설치	.5
T7	사용하기 쉬운	.5
T8	가지고 다닐 수 있는	2.0
T9	변경하기 쉬움	1.0
T10	병발 사정	1.0
T11	특별한 보안 목표 포함	1.0
T12	제 3 자에게 직접 액세스를 제공합니다.	1.0
T13	특별한 사용자 교육 시설이 필요합니다.	1.0

이러한 요소 중 다수는 프로젝트의 비 기능적 요구 사항을 나타냅니다.

Step 2.2 − 13 개 요소 각각에 대해 프로젝트 및 비율을 0 (관련 없음)에서 5 (매우 중요)까지 평가합니다.

Step 2.3 − 요인의 영향 가중치와 프로젝트에 대한 정격 값에서 요인의 영향을 다음과 같이 계산합니다.

Impact of the Factor = Impact Weight × Rated Value

Step (2.4)− 모든 요인의 영향의 합을 계산합니다. 이것은 아래 표에 주어진 총 기술 계수 (TFactor)를 제공합니다.

인자	기술	무게 (W)	정격 값 (0 ~ 5) (RV)	영향 (I = W × RV)
T1	분산 시스템	2.0
T2	응답 시간 또는 처리량 성능 목표	1.0
T3	최종 사용자 효율성	1.0
T4	복잡한 내부 처리	1.0
T5	코드는 재사용 가능해야합니다.	1.0
T6	간편한 설치	.5
T7	사용하기 쉬운	.5
T8	가지고 다닐 수 있는	2.0
T9	변경하기 쉬움	1.0
T10	병발 사정	1.0
T11	특별한 보안 목표 포함	1.0
T12	제 3 자에게 직접 액세스를 제공합니다.	1.0
T13	특별한 사용자 교육 시설이 필요합니다.	1.0
Total Technical Factor (TFactor)

Step 2.5 − TCF (Technical Complexity Factor) 계산 −

TCF = 0.6 + (0.01 × TFactor)

3 단계 : 환경 복잡성 조정

Step 3.1 − 프로젝트 실행에 영향을 미칠 수있는 8 가지 환경 요인과 다음 표에 나와있는 해당 가중치를 고려합니다.

인자	기술	무게
F1	사용되는 프로젝트 모델에 익숙 함	1.5
F2	신청 경험	.5
F3	객체 지향 경험	1.0
F4	리드 분석가 역량	.5
F5	자극	1.0
F6	안정적인 요구 사항	2.0
F7	파트 타임 직원	-1.0
F8	어려운 프로그래밍 언어	-1.0

Step 3.2 − 8 가지 요인 각각에 대해 프로젝트 및 비율을 0 (관련 없음)에서 5 (매우 중요)까지 평가합니다.

Step 3.3 − 요인의 영향 가중치와 프로젝트에 대한 정격 값에서 요인의 영향을 다음과 같이 계산합니다.

Impact of the Factor = Impact Weight × Rated Value

Step 3.4− 모든 요인의 영향의 합을 계산합니다. 이것은 다음 표와 같이 총 환경 계수 (EFactor)를 제공합니다.

인자	기술	무게 (W)	정격 값 (0 ~ 5) (RV)	영향 (I = W × RV)
F1	사용되는 프로젝트 모델에 익숙 함	1.5
F2	신청 경험	.5
F3	객체 지향 경험	1.0
F4	리드 분석가 역량	.5
F5	자극	1.0
F6	안정적인 요구 사항	2.0
F7	파트 타임 직원	-1.0
F8	어려운 프로그래밍 언어	-1.0
Total Environment Factor (EFactor)

Step 3.5 − EF (Environmental Factor) 계산 −

1.4 + (-0.03 × EFactor)

4 단계 : 조정 된 사용 사례 포인트 (UCP) 계산

조정 된 사용 사례 포인트 (UCP)를 다음과 같이 계산합니다.

UCP = UUCP × TCF × EF

유스 케이스 포인트의 장단점

유스 케이스 포인트의 장점

• UCP는 사용 사례를 기반으로하며 프로젝트 수명주기 초기에 측정 할 수 있습니다.

• UCP (크기 추정)는 프로젝트를 구현하는 팀의 규모, 기술 및 경험과 무관합니다.

• UCP 기반 추정치는 숙련 된 사람들이 추정을 수행 할 때 실제에 가까운 것으로 나타났습니다.

• UCP는 사용하기 쉽고 추가 분석이 필요하지 않습니다.

• 사용 사례는 요구 사항을 설명하기위한 선택 방법으로 광범위하게 사용되고 있습니다. 이러한 경우 UCP가 가장 적합한 추정 기법입니다.

사용 사례 포인트의 단점

• UCP는 요구 사항이 유스 케이스 형식으로 작성된 경우에만 사용할 수 있습니다.

• 목표 지향적이고 잘 작성된 사용 사례에 따라 다릅니다. 사용 사례가 적절하지 않거나 균일하게 구조화되지 않은 경우 결과 UCP가 정확하지 않을 수 있습니다.

• 기술 및 환경 요인은 UCP에 큰 영향을 미칩니다. 기술 및 환경 요인에 가치를 할당하는 동안주의를 기울여야합니다.

• UCP는 전체 프로젝트 크기의 초기 추정에 유용하지만 팀의 반복 작업을 추진하는 데는 훨씬 덜 유용합니다.

Delphi Method원래는 전문가 패널에 의존하는 체계적이고 상호 작용적인 예측 방법으로 개발 된 구조화 된 커뮤니케이션 기술입니다. 전문가들은 2 회 이상 설문지에 답합니다. 각 라운드 후 진행자는 판단 이유와 함께 이전 라운드의 전문가 예측에 대한 익명 요약을 제공합니다. 그런 다음 전문가는 패널의 다른 구성원의 답변에 비추어 이전 답변을 수정하도록 권장됩니다.

이 과정에서 답변의 범위가 줄어들고 그룹은 "정답"답변으로 수렴 할 것으로 믿어집니다. 마지막으로 사전 정의 된 중지 기준 (예 : 라운드 수, 합의 달성 및 결과의 안정성) 후에 프로세스가 중지되고 최종 라운드의 평균 또는 중간 점수가 결과를 결정합니다.

Delphi Method는 1950-1960 년대 RAND Corporation에서 개발되었습니다.

광대역 델파이 기술

1970 년대에 Barry Boehm과 John A. Farquhar는 Delphi Method의 Wideband Variant를 시작했습니다. "광대역"이라는 용어는 Delphi 방법에 비해 Wideband Delphi 기술이 참가자 간의 상호 작용과 의사 소통을 더 많이 포함했기 때문에 사용되었습니다.

Wideband Delphi Technique에서 평가 팀은 프로젝트 관리자, 중재자, 전문가 및 개발 팀 대표로 구성되며 3-7 명의 구성원 팀을 구성합니다. 두 회의가 있습니다-

• 킥오프 회의
• 견적 회의

광대역 델파이 기술 – 단계

Step 1 − 추정 팀과 중재자를 선택합니다.

Step 2− 중재자는 킥오프 회의를 진행하여 팀에게 문제 사양과 높은 수준의 작업 목록, 모든 가정 또는 프로젝트 제약을 제시합니다. 팀은 문제 및 추정 문제 (있는 경우)에 대해 논의합니다. 그들은 또한 추정 단위를 결정합니다. 중재자는 전체 토론을 안내하고, 시간을 모니터링하고, 킥오프 회의 후 문제 사양, 상위 수준 작업 목록, 가정 및 결정된 추정 단위가 포함 된 구조화 된 문서를 준비합니다. 그런 다음 다음 단계를 위해이 문서의 사본을 전달합니다.

Step 3 − 그런 다음 각 추정 팀원이 개별적으로 상세한 WBS를 생성하고 WBS의 각 작업을 추정하고 가정을 문서화합니다.

Step 4− 중재자는 견적 회의를 위해 견적 팀을 호출합니다. 예상 팀원 중 한 명이 예상치가 준비되지 않았다고 응답하면 중재자는 더 많은 시간을 제공하고 회의 초대를 다시 보냅니다.

Step 5 − 전체 견적 팀이 견적 회의를 위해 모입니다.

Step 5.1 − 견적 회의 시작시 중재자는 각 팀원으로부터 초기 견적을 수집합니다.

Step 5.2− 그런 다음 화이트 보드에 차트를 그립니다. 그는 해당 이름을 공개하지 않고 각 구성원의 총 프로젝트 추정치를 1 라운드 줄에 X로 표시합니다. 추정 팀은 초기에 클 수있는 추정 범위에 대한 아이디어를 얻습니다.

Step 5.3− 각 팀원은 자신이 만든 세부 작업 목록을 소리내어 읽고 가정을 확인하고 질문이나 문제를 제기합니다. 작업 견적은 공개되지 않습니다.

개별 세부 작업 목록을 결합하면보다 완전한 작업 목록에 기여합니다.

Step 5.4 − 그런 다음 팀은 도달 한 작업, 가정 및 추정 문제에 대한 의심 / 문제에 대해 논의합니다.

Step 5.5− 그런 다음 각 팀원은 자신의 작업 목록과 가정을 다시 확인하고 필요한 경우 변경합니다. 작업 추정은 + N Hrs로 표시되는 논의에 따라 조정이 필요할 수도 있습니다. 더 많은 노력과 –N Hrs. 적은 노력으로.

그런 다음 팀 구성원은 전체 프로젝트 예상치에 도달하기 위해 작업 예상치의 변경 사항을 결합합니다.

Step 5.6 − 중재자는 모든 팀원으로부터 변경된 추정치를 수집하여 라운드 2 라인에 플로팅합니다.

이번 라운드에서는 합의 기반이 더 많기 때문에 이전에 비해 범위가 좁아집니다.

Step 5.7 − 그런 다음 팀은 자신이 수정 한 작업과 가정에 대해 논의합니다.

Step 5.8− 그런 다음 각 팀원은 자신의 작업 목록과 가정을 다시 확인하고 필요한 경우 변경합니다. 작업 견적은 토론을 기반으로 조정이 필요할 수도 있습니다.

그런 다음 팀 구성원은 작업 견적의 변경 사항을 다시 한 번 결합하여 전체 프로젝트 견적에 도달합니다.

Step 5.9 − 진행자는 모든 회원으로부터 변경된 견적을 다시 수집하여 Round 3 라인에 플로팅합니다.

다시 말하지만, 이번 라운드에서는 이전 라운드에 비해 범위가 좁아집니다.

Step 5.10 − 다음 기준 중 하나가 충족 될 때까지 5.7, 5.8, 5.9 단계를 반복합니다.

• 결과는 허용 가능한 좁은 범위로 수렴됩니다.
• 모든 팀원은 최신 추정치를 변경하기를 꺼립니다.
• 할당 된 예상 회의 시간이 끝났습니다.

Step 6 − 그런 다음 프로젝트 관리자는 추정 회의의 결과를 수집합니다.

Step 6.1 − 그는 개별 작업 목록과 해당 견적을 단일 마스터 작업 목록으로 컴파일합니다.

Step 6.2 − 그는 또한 개별 가정 목록을 결합합니다.

Step 6.3 − 그런 다음 추정 팀과 함께 최종 작업 목록을 검토합니다.

광대역 델파이 기술의 장단점

장점

• Wideband Delphi Technique는 노력을 추정하기위한 합의 기반 추정 기법입니다.
• 작업 수행 시간을 예측할 때 유용합니다.
• 경험이 풍부한 사람들의 참여와 개별 평가는 신뢰할 수있는 결과로 이어질 것입니다.
• 작업을 수행 할 사람들은 추정을하므로 유효한 추정을합니다.
• 전체적으로 유지되는 익명 성은 모든 사람이 자신의 결과를 자신있게 표현할 수 있도록합니다.
• 아주 간단한 기술입니다.
• 가정은 문서화되고 논의되고 동의됩니다.

단점

• 관리 지원이 필요합니다.
• 추정 결과는 경영진이 듣고 싶어하는 것과 다를 수 있습니다.

3 점 추정은 세 가지 값을 봅니다.

• 가장 낙관적 인 추정치 (O),
• 가능성이 가장 높은 추정치 (M) 및
• 비관적 추정 (최소 가능성 추정 (L)).

업계에서 3 점 추정 및 PERT에 대해 약간의 혼란이있었습니다. 그러나 기술은 다릅니다. 두 가지 기술을 배우면서 차이점을 알게 될 것입니다. 또한 PERT 기술이 끝나면 차이점을 대조하여 제시합니다. 먼저보고 싶다면 할 수 있습니다.

3 점 추정치 (E)는 단순 평균을 기반으로하며 삼각형 분포를 따릅니다.

E = (O + M + L) / 3

표준 편차

삼각 분포에서

평균 = (O + M + L) / 3

표준 편차 = √ [((O − E) ² + (M − E) ² + (L − E) ² ) / 2]

3 점 추정 단계

Step 1 − WBS에 도착합니다.

Step 2 − 각 작업에 대해 가장 낙관적 인 추정치 (O), 가장 가능성이 높은 추정치 (M), 비관적 추정치 (L)의 세 가지 값을 찾으십시오.

Step 3 − 세 값의 평균을 계산합니다.

Mean = (O + M + L) / 3

Step 4− 작업의 3 점 추정치를 계산합니다. 3 점 추정치는 평균입니다. 그 후,

E = Mean = (O + M + L) / 3

Step 5 − 작업의 표준 편차를 계산합니다.

Standard Deviation (SD) = √ [((O − E)² + (M − E)² + (L - E)²)/2]

Step 6 − WBS의 모든 작업에 대해 2, 3, 4 단계를 반복합니다.

Step 7 − 프로젝트의 3 점 추정치를 계산합니다.

E (Project) = ∑ E (Task)

Step 8 − 프로젝트의 표준 편차를 계산합니다.

SD (Project) = √ (∑SD (Task)²)

프로젝트 추정치를 신뢰 수준으로 변환

이렇게 계산 된 3 점 추정치 (E)와 표준 편차 (SD)는 프로젝트 추정치를 "신뢰 수준"으로 변환하는 데 사용됩니다.

변환은-

• E +/- SD의 신뢰 수준은 약 68 %입니다.
• E 값 +/– 1.645 × SD의 신뢰 수준은 약 90 %입니다.
• E 값 +/– 2 × SD의 신뢰 수준은 약 95 %입니다.
• E 값 +/– 3 × SD의 신뢰 수준은 약 99.7 %입니다.

일반적으로 95 % 신뢰 수준, 즉 E Value + 2 × SD는 모든 프로젝트 및 작업 추정에 사용됩니다.

PERT (Project Evaluation and Review Technique) 추정은 가장 낙관적 인 추정 (O), 가장 가능성이 높은 추정 (M) 및 비관적 추정 (최소 가능성 추정 (L))의 세 가지 값을 고려합니다. 업계에서 3 점 추정 및 PERT에 대해 약간의 혼란이있었습니다. 그러나 기술은 다릅니다. 두 가지 기술을 배우면서 차이점을 알게 될 것입니다. 또한이 장의 끝에서 차이점을 대조하여 제시합니다.

PERT는 가장 낙관적 인 추정치 (O), 가장 가능성있는 추정치 (M), 비관적 추정치 (최소 가능성 추정치 (L))의 세 가지 값을 기반으로합니다. 가장 가능성이 높은 추정치는 다른 두 추정치 (낙관적 및 비관적)보다 4 배 더 가중치가 있습니다.

PERT 추정치 (E)는 가중 평균을 기반으로하며 베타 분포를 따릅니다.

E = (O + 4 × M + L)/6

PERT는 CPM (Critical Path Method)과 함께 자주 사용됩니다. CPM은 프로젝트에서 중요한 작업에 대해 알려줍니다. 이러한 작업이 지연되면 프로젝트가 지연됩니다.

표준 편차

표준 편차 (SD)는 추정치의 변동성 또는 불확실성을 측정합니다.

베타 배포에서는

평균 = (O + 4 × M + L) / 6

표준 편차 (SD) = (L − O) / 6

PERT 추정 단계

Step (1) − WBS에 도착합니다.

Step (2) − 각 작업에 대해 가장 낙관적 인 추정치 (O), 가장 가능성이 높은 추정치 (M) 및 비관적 추정치 (L) 세 값을 찾습니다.

Step (3) − PERT 평균 = (O + 4 × M + L) / 6

PERT 평균 = (O + 4 × M + L) / 3

Step (4) − 작업의 표준 편차를 계산합니다.

표준 편차 (SD) = (L − O) / 6

Step (6) − WBS의 모든 작업에 대해 2, 3, 4 단계를 반복합니다.

Step (7) − 프로젝트의 PERT 추정치를 계산합니다.

E (프로젝트) = ∑ E (작업)

Step (8) − 프로젝트의 표준 편차를 계산합니다.

SD (프로젝트) = √ (ΣSD (작업) ² )

프로젝트 추정치를 신뢰 수준으로 변환

이렇게 계산 된 PERT 추정치 (E) 및 표준 편차 (SD)는 프로젝트 추정치를 신뢰 수준으로 변환하는 데 사용됩니다.

변환은

• E +/- SD의 신뢰 수준은 약 68 %입니다.
• E 값 +/– 1.645 × SD의 신뢰 수준은 약 90 %입니다.
• E 값 +/– 2 × SD의 신뢰 수준은 약 95 %입니다.
• E 값 +/- 3 × SD의 신뢰 수준은 약 99.7 %입니다.

일반적으로 95 % 신뢰 수준, 즉 E Value + 2 × SD는 모든 프로젝트 및 작업 추정에 사용됩니다.

3 점 추정과 PERT의 차이점

다음은 3 점 추정과 PERT의 차이점입니다.

3 점 추정	건방진
단순 평균	가중 평균
삼각형 분포를 따릅니다.	베타 배포를 따릅니다
소규모 반복 프로젝트에 사용	반복되지 않는 대규모 프로젝트, 일반적으로 R & D 프로젝트에 사용됩니다. CPM (중요 경로 방법)과 함께 사용
E = 평균 = (O + M + L) / 3 이것은 단순한 평균입니다	E = 평균 = (O + 4 × M + L) / 6 이것은 가중 평균입니다.
SD = √ [((O − E) 2 + (M − E) 2 + (L − E) 2 ) / 2]	SD = (L − O) / 6

Analogous Estimation유사한 과거 프로젝트 정보를 사용하여 현재 프로젝트의 기간 또는 비용을 추정하므로 "유추"라는 단어가 사용됩니다. 현재 프로젝트에 대한 제한된 정보가있을 때 유사한 추정을 사용할 수 있습니다.

경영진이 프로젝트를 수행 할 가치가 있는지 여부를 결정하기 위해 의사 결정 데이터가 필요하기 때문에 프로젝트 관리자가 새 프로젝트에 대한 비용 및 기간 추정치를 제공하도록 요청받는 상황이 자주 발생합니다. 일반적으로 프로젝트 관리자 나 조직의 다른 누구도 새 프로젝트와 같은 프로젝트를 수행 한 적이 없지만 경영진은 여전히 ​​정확한 비용 및 기간 추정을 원합니다.

이러한 경우 유사한 추정이 최상의 솔루션입니다. 완벽하지는 않지만 과거 데이터를 기반으로하므로 정확합니다. 유사 추정은 구현하기 쉬운 기술입니다. 프로젝트 성공률은 초기 추정치에 비해 최대 60 %까지 가능합니다.

유사 추정 – 정의

유사 추정은 과거 데이터의 매개 변수 값을 미래 활동에 대한 유사한 매개 변수를 추정하기위한 기준으로 사용하는 기술입니다. 매개 변수 예 : 범위, 비용 및 기간. 규모의 측정 예-크기, 무게 및 복잡성.

프로젝트 관리자와 팀의 경험과 판단이 추정 프로세스에 적용되기 때문에 과거 정보와 전문가 판단의 조합으로 간주됩니다.

유사한 추정 요구 사항

유사한 추정을 위해 다음은 요구 사항입니다-

• 이전 및 진행중인 프로젝트의 데이터
  • 각 팀원의 주당 근무 시간
  • 프로젝트 완료에 필요한 비용
• 현재 프로젝트에 가까운 프로젝트
• 현재 프로젝트가 새로운 프로젝트이고 과거 프로젝트가 유사하지 않은 경우
  • 현재 프로젝트와 유사한 과거 프로젝트의 모듈
  • 현재 프로젝트와 유사한 과거 프로젝트의 활동
  • 선택한 항목의 데이터
• 예상에 대한 경험있는 판단을 보장하기 위해 프로젝트 관리자 및 평가 팀의 참여.

유사한 추정 단계

프로젝트 관리자와 팀은 유사한 추정을 공동으로 수행해야합니다.

• Step 1 − 현재 프로젝트의 도메인을 식별합니다.

• Step 2 − 현재 프로젝트의 기술을 식별합니다.

• Step 3− 유사한 프로젝트 데이터를 사용할 수있는 경우 조직 데이터베이스를 확인합니다. 가능한 경우 단계 (4)로 이동합니다. 그렇지 않으면 단계 (6)로 이동합니다.

• Step 4 − 현재 프로젝트를 확인 된 과거 프로젝트 데이터와 비교합니다.

• Step 5− 현재 프로젝트의 기간 및 비용 추정치에 도착합니다. 이것은 프로젝트의 유사한 추정을 끝냅니다.

• Step 6 − 과거 프로젝트에 현재 프로젝트와 유사한 모듈이있는 경우 조직 데이터베이스를 확인합니다.

• Step 7 − 과거 프로젝트에 현재 프로젝트와 유사한 활동이있는 경우 조직 데이터베이스를 확인합니다.

• Step 8 − 모든 정보를 수집하고 전문가의 판단을 사용하여 현재 프로젝트의 기간 및 비용 추정치에 도달합니다.

유사 추정의 장점

• 유사 추정은 세부 사항이 거의 알려지지 않은 경우 프로젝트의 초기 단계에서 더 나은 추정 방법입니다.

• 이 기술은 간단하고 추정에 걸리는 시간이 매우 적습니다.

• 기술이 조직의 과거 프로젝트 데이터를 기반으로하기 때문에 조직의 성공률이 높을 것으로 예상 할 수 있습니다.

• 유사한 추정을 사용하여 개별 작업의 노력과 기간을 추정 할 수도 있습니다. 따라서 WBS에서 작업을 추정 할 때 Analogy를 사용할 수 있습니다.

프로젝트 관리 및 시스템 엔지니어링에서 WBS (Work Breakdown Structure)는 프로젝트를 더 작은 구성 요소로 결과물 지향적으로 분해하는 것입니다. WBS는 팀의 작업을 관리 가능한 섹션으로 구성하는 핵심 프로젝트 결과물입니다. PMBOK (Project Management Body of Knowledge)는 WBS를 "프로젝트 팀이 실행할 작업의 전달 가능한 계층 적 분해"로 정의합니다.

WBS 요소는 제품, 데이터, 서비스 또는 이들의 조합 일 수 있습니다. WBS는 또한 일정 개발 및 제어를위한 지침을 제공하는 것과 함께 상세한 비용 산정 및 제어에 필요한 프레임 워크를 제공합니다.

WBS 대표

WBS는 프로젝트 작업 활동의 계층 적 목록으로 표시됩니다. WBS에는 두 가지 형식이 있습니다.

• 개요보기 (들여 쓰기 형식)
• 트리 구조보기 (조직도)

먼저 WBS를 준비하기 위해 개요보기를 사용하는 방법에 대해 논의하겠습니다.

개요보기

개요보기는 매우 사용자 친화적 인 레이아웃입니다. 전체 프로젝트에 대한 좋은보기를 제공하고 쉽게 수정할 수 있습니다. 숫자를 사용하여 프로젝트의 다양한 단계를 기록합니다. 다음과 비슷해 보입니다.

• Software Development

• Scope

  • 프로젝트 범위 결정
  • 안전한 프로젝트 후원
  • 예비 자원 정의
  • 핵심 자원 확보
  • 범위 완료

• Analysis/Software Requirements

  • 요구 분석 수행
  • 예비 소프트웨어 사양 초안
  • 예비 예산 개발
  • 팀과 함께 소프트웨어 사양 / 예산 검토
  • 소프트웨어 사양에 대한 피드백 통합
  • 배송 일정 개발
  • 진행을위한 승인 획득 (개념, 일정 및 예산)
  • 필요한 리소스 확보
  • 분석 완료

• Design

  • 예비 소프트웨어 사양 검토
  • 기능 사양 개발
  • 계속하려면 승인 받기
  • 디자인 완료

• Development

  • 기능 사양 검토
  • 모듈 식 / 계층 설계 매개 변수 식별
  • 코드 개발
  • 개발자 테스트 (기본 디버깅)
  • 개발 완료

• Testing

  • 제품 사양을 사용하여 단위 테스트 계획 개발
  • 제품 사양을 사용하여 통합 테스트 계획 개발

• Training

  • 최종 사용자를위한 교육 사양 개발
  • 교육 제공 방법 (온라인, 강의실 등) 식별
  • 교육 자료 개발
  • 교육 자료 마무리
  • 교육 전달 메커니즘 개발
  • 교육 자료 완료

• Deployment

  • 최종 배포 전략 결정
  • 배포 방법론 개발
  • 안전한 배포 리소스
  • 지원 직원 교육
  • 소프트웨어 배포
  • 배포 완료

이제 트리 구조보기를 살펴 보겠습니다.

트리 구조보기

트리 구조보기는 전체 프로젝트에 대해 매우 이해하기 쉬운보기를 제공합니다. 다음 그림은 트리 구조보기의 모양을 보여줍니다. 이러한 유형의 조직도 구조는 MS-Word에서 사용할 수있는 기능을 사용하여 쉽게 그릴 수 있습니다.

WBS의 유형

WBS에는 두 가지 유형이 있습니다.

• Functional WBS− 기능적 WBS에서는 개발할 응용 프로그램의 기능에 따라 시스템이 손상됩니다. 이것은 시스템의 크기를 추정하는 데 유용합니다.

• Activity WBS− 활동 WBS에서 시스템의 활동에 따라 시스템이 중단됩니다. 활동은 작업으로 더 나뉩니다. 이는 시스템의 노력과 일정을 추정하는 데 유용합니다.

크기 추정

Step 1 − 기능적인 WBS로 시작합니다.

Step 2 − 리프 노드를 고려하십시오.

Step 3 − Analogy 또는 Wideband Delphi를 사용하여 크기 추정치를 얻습니다.

노력 추정

Step 1− Wideband Delphi 기술을 사용하여 WBS를 구성합니다. 작업은 8 시간을 초과하지 않는 것이 좋습니다. 작업의 기간이 더 길면 분할하십시오.

Step 2 − Wideband Delphi Technique 또는 Three-point Estimation을 사용하여 작업에 대한 노력 추정치에 도달합니다.

스케줄링

WBS가 준비되고 크기 및 노력 추정치가 알려지면 작업을 예약 할 준비가 된 것입니다.

작업을 예약하는 동안 특정 사항을 고려해야합니다.

• Precedence − 다른 작업보다 먼저 발생해야하는 작업이 다른 작업보다 우선한다고합니다.

• Concurrence − 동시 작업은 동시에 (병렬로) 발생할 수있는 작업입니다.

• Critical Path − 프로젝트 완료 날짜가 의존하는 특정 일련의 순차적 작업.

  • 모든 프로젝트에는 중요한 경로가 있습니다.
  • 중요하지 않은 작업을 가속화한다고해서 일정이 직접 단축되는 것은 아닙니다.

중요 경로 방법

CPM (Critical Path Method)은 중요 경로를 결정하고 최적화하는 프로세스입니다. 중요하지 않은 경로 작업은 완료 날짜에 영향을주지 않고 이전 또는 이후에 시작할 수 있습니다.

현재 경로를 줄이면 중요 경로가 다른 경로로 변경 될 수 있습니다. 예를 들어, 이전 그림에서 WBS의 경우 임계 경로는 다음과 같습니다.

프로젝트 완료 날짜는 일련의 순차적 작업을 기반으로하므로 이러한 작업을 중요 작업이라고합니다.

프로젝트 완료 날짜는 교육, 문서 및 배포를 기반으로하지 않습니다. 이러한 작업을 중요하지 않은 작업이라고합니다.

작업 종속성 관계

일정을 잡는 동안 특정 시간에 작업 종속성 관계를 고려해야 할 수 있습니다. 중요한 작업 종속성 관계는 다음과 같습니다.

• 완료 후 시작 (FS)
• 완료 후 완료 (FF)

완료 후 시작 (FS)

FS (Finish-to-Start) 태스크 종속성 관계에서 태스크 B는 태스크 A가 완료 될 때까지 시작할 수 없습니다.

완료 후 완료 (FF)

완료 후 완료 (FF) 태스크 종속성 관계에서 태스크 B는 태스크 A가 완료 될 때까지 완료 할 수 없습니다.

간트 차트

Gantt 차트는 1896 년 Karol Adamiecki와 1910 년대 Henry Gantt가 개별적으로 조정 한 막대 차트 유형으로, 프로젝트 일정을 보여줍니다. Gantt 차트는 프로젝트의 최종 요소와 요약 요소의 시작 및 종료 날짜를 보여줍니다.

그림 2의 개요 형식을 Microsoft Project로 가져와 Gantt 차트보기를 얻을 수 있습니다.

마일스톤

마일스톤은 일정에서 중요한 단계입니다. 기간은 0이며 특정 작업 세트를 완료했음을 표시하는 데 사용됩니다. 마일스톤은 일반적으로 다이아몬드로 표시됩니다.

예를 들어 위의 Gantt 차트에서 디자인 완료 및 개발 완료는 다이아몬드 모양으로 표시되는 마일스톤으로 표시됩니다.

마일스톤은 계약 조건과 연결될 수 있습니다.

WBS를 사용한 추정의 장점

WBS는 프로젝트 추정 프로세스를 상당히 단순화합니다. 다른 추정 기술에 비해 다음과 같은 이점을 제공합니다.

• WBS에서는 프로젝트가 수행해야 할 전체 작업이 식별됩니다. 따라서 프로젝트 이해 관계자와 WBS를 검토하면 원하는 프로젝트 결과물을 제공하는 데 필요한 작업을 생략 할 가능성이 줄어 듭니다.

• WBS는 더 정확한 비용 및 일정 견적을 제공합니다.

• 프로젝트 관리자는 WBS를 마무리하기 위해 팀 참여를 얻습니다. 팀의 이러한 참여는 프로젝트에 대한 열정과 책임감을 생성합니다.

• WBS는 작업 할당의 기초를 제공합니다. 정확한 작업은 성취에 대한 책임이있는 특정 팀원에게 할당됩니다.

• WBS를 사용하면 작업 수준에서 모니터링 및 제어가 가능합니다. 이를 통해 진행 상황을 측정하고 프로젝트가 제 시간에 전달되도록 할 수 있습니다.

포커 견적 계획

Planning Poker는 추정을위한 합의 기반 기법으로 주로 스크럼에서 사용자 스토리의 노력이나 상대적 크기를 추정하는 데 사용됩니다.

플래닝 포커는 광대역 델파이 기법, 유사 추정, WBS를 사용한 추정의 세 가지 추정 기법을 결합합니다.

Planning Poker는 2002 년 James Grenning에 의해 처음 정의되고 이름이 지정되었으며 나중에 Mike Cohn이 그의 저서 "Agile Estimating and Planning"에서 인기를 얻었습니다.

포커 추정 기법 계획

Planning Poker Estimation Technique에서 사용자 스토리에 대한 추정치는 플래닝 포커를 통해 도출됩니다. 전체 스크럼 팀이 참여하여 신속하지만 신뢰할 수있는 추정치를 산출합니다.

• 플래닝 포커는 한 벌의 카드로 플레이됩니다. 피보나치 수열이 사용됨에 따라 카드에는 1, 2, 3, 5, 8, 13, 21, 34 등의 숫자가 있습니다.이 숫자는 "스토리 포인트"를 나타냅니다. 각 견적자는 카드 한 벌을 가지고 있습니다. 카드의 숫자는 팀원 중 한 명이 카드를 들고있을 때 모든 팀원이 볼 수있을만큼 충분히 커야합니다.

• 팀원 중 한 명이 중재자로 선택됩니다. 중재자는 평가중인 사용자 스토리에 대한 설명을 읽습니다. 견적가가 질문이 있으면 제품 소유자가 답변합니다.

• 각 견적자는 자신의 견적을 나타내는 카드를 개인적으로 선택합니다. 모든 견적가가 선택하기 전까지는 카드가 표시되지 않습니다. 이때 모든 팀원이 각 견적을 볼 수 있도록 모든 카드를 동시에 뒤집어 들고 있습니다.

• 첫 번째 라운드에서는 추정치가 다를 가능성이 큽니다. 높고 낮은 추정치는 추정의 이유를 설명합니다. 모든 논의는 이해를위한 것이며 개인적으로 어떠한 것도 다루지 않도록주의해야합니다. 중재자는 동일하게 보장해야합니다.

• 팀은 몇 분 동안 이야기와 추정치를 논의 할 수 있습니다.

• 사회자는 특정 이야기가 전개 될 때 도움이 될 토론에 대해 메모를 할 수 있습니다. 토론 후 각 견적자는 카드를 다시 선택하여 재평가합니다. 카드는 모든 사람이 추정 할 때까지 다시 한 번 비공개로 유지되며, 그 시점에서 동시에 뒤집 힙니다.

추정치가 스토리에 사용할 수있는 단일 추정치로 수렴 될 때까지 프로세스를 반복하십시오. 추정 라운드 수는 사용자 스토리마다 다를 수 있습니다.

포커 견적 계획의 이점

계획 포커는 세 가지 추정 방법을 결합합니다-

Expert Opinion− 전문가 의견 기반 추정 방식에서 전문가는 무언가가 얼마나 오래 걸리거나 얼마나 커질 것인지 질문합니다. 전문가는 자신의 경험이나 직감 또는 직감에 따라 추정치를 제공합니다. Expert Opinion Estimation은 일반적으로 시간이 많이 걸리지 않으며 일부 분석 방법에 비해 더 정확합니다.

Analogy− 유추 추정은 사용자 스토리의 비교를 사용합니다. 추정 된 사용자 스토리는 이전에 구현 된 유사한 사용자 스토리와 비교되어 추정이 입증 된 데이터를 기반으로하므로 정확한 결과를 제공합니다.

Disaggregation− 세분화 추정은 사용자 스토리를 더 작고 추정하기 쉬운 사용자 스토리로 분할하여 수행됩니다. 스프린트에 포함 할 사용자 스토리는 일반적으로 개발하는 데 2 ​​~ 5 일 정도 걸립니다. 따라서 시간이 더 오래 걸릴 수있는 사용자 스토리는 더 작은 사용 사례로 분할해야합니다. 이 접근 방식은 또한 비교할만한 많은 스토리가 있음을 보장합니다.

테스트 노력은 정해진 기간을 기반으로하지 않습니다. 테스트 완료 여부에 관계없이 미리 결정된 일정이 설정 될 때까지 노력이 계속됩니다.

이것은 대부분 전통적으로 test effort estimation 의 일부입니다 development estimation. Wideband Delphi, Three-point Estimation, PERT 및 WBS와 같이 WBS를 사용하는 추정 기법의 경우에만 테스트 활동의 추정 값을 얻을 수 있습니다.

추정치를 FP (Function Points)로 얻은 경우 Caper Jones에 따라

Number of Test Cases = (Number of Function Points) × 1.2

테스트 케이스의 수가 확보되면 조직 데이터베이스에서 생산성 데이터를 가져 와서 테스트에 필요한 노력에 도달 할 수 있습니다.

개발 노력 비율

필요한 테스트 노력은 개발 노력의 정비례 또는 비율입니다. LOC (Lines of Code) 또는 FP (Function Point)를 사용하여 개발 노력을 추정 할 수 있습니다. 그런 다음 조직 데이터베이스에서 테스트 노력의 백분율을 얻습니다. 이렇게 얻은 백분율은 테스트를위한 노력 추정치에 도달하는 데 사용됩니다.

테스트 프로젝트 추정

현재 여러 조직이 고객에게 독립적 인 검증 및 검증 서비스를 제공하고 있으며 이는 프로젝트 활동이 전적으로 테스트 활동임을 의미합니다.

테스트 프로젝트를 추정하려면 소프트웨어 테스트 수명주기 동안 다양한 프로젝트에 대한 경험이 필요합니다. 테스트 프로젝트를 추정 할 때 다음 사항을 고려하십시오.

• 팀 기술
• 도메인 지식
• 응용 프로그램의 복잡성
• 역사적 자료
• 프로젝트의 버그주기
• 자원 가용성
• 생산성 변화
• 시스템 환경 및 다운 타임

추정 기법 테스트

다음 테스트 추정 기술은 정확하고 널리 사용됩니다.

• PERT 소프트웨어 테스트 추정 기술
• UCP 방법
• WBS
• 광대역 델파이 기술
• 기능 포인트 / 테스트 포인트 분석
• 백분율 분포
• 경험 기반 테스트 추정 기법

PERT 소프트웨어 테스트 추정 기법

PERT 소프트웨어 테스트 추정 기법은 각 테스트 작업을 하위 작업으로 분류 한 다음 각 하위 작업에 대해 세 가지 유형의 추정을 수행하는 통계 방법을 기반으로합니다.

이 기술에서 사용되는 공식은 다음과 같습니다.

Test Estimate = (O + (4 × M) + E)/6

어디,

O = 낙관적 추정 (아무것도 잘못되지 않고 모든 조건이 최적 인 최상의 시나리오).

M = 대부분의 추정치 (가장 예상되는 기간이며 약간의 문제가있을 수 있지만 대부분은 올바르게 진행됩니다).

L = 비관적 추정 (모든 것이 잘못되는 최악의 시나리오).

기술에 대한 표준 편차는 다음과 같이 계산됩니다.

Standard Deviation (SD) = (E − O)/6

사용 사례 포인트 방법

UCP 방법은 조정되지 않은 액터 가중치와 조정되지 않은 사용 사례 가중치를 계산하여 소프트웨어 테스트 추정치를 결정하는 사용 사례를 기반으로합니다.

사용 사례는 관련 응용 프로그램과 상호 작용하는 다른 사용자, 시스템 또는 기타 이해 관계자를 지정하는 문서입니다. 그들은“배우”로 명명됩니다. 상호 작용은 시나리오라고하는 다양한 행동 또는 흐름을 통해 모든 이해 관계자의 이익을 보호하는 정의 된 목표를 달성합니다.

Step 1− 번호를 세십시오. 배우의. 배우는 긍정적, 부정적, 예외적입니다.

Step 2 − 조정되지 않은 액터 가중치를 다음과 같이 계산합니다.

Unadjusted Actor Weights = Total no. of Actors

Step 3 − 사용 사례의 수를 세십시오.

Step 4 − 조정되지 않은 사용 사례 가중치를 다음과 같이 계산합니다.

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 − 조정되지 않은 사용 사례 포인트를 다음과 같이 계산합니다.

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6− 기술 / 환경 요인 (TEF)을 결정합니다. 사용할 수없는 경우 0.50으로 간주합니다.

Step 7 − 조정 된 사용 사례 포인트를 다음과 같이 계산합니다.

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 − 총 노력을 다음과 같이 계산합니다.

Total Effort = Adjusted Use-Case Point × 2

작업 분할 구조

Step 1 − 테스트 프로젝트를 작은 조각으로 나누어 WBS를 만듭니다.

Step 2 − 모듈을 하위 모듈로 나눕니다.

Step 3 하위 모듈을 기능별로 더 나눕니다.

Step 4 − 기능을 하위 기능으로 나눕니다.

Step 5 − 모든 테스트 요구 사항을 검토하여 WBS에 추가되었는지 확인합니다.

Step 6 − 팀이 완료해야하는 작업 수를 파악합니다.

Step 7 − 각 작업에 대한 노력을 추정합니다.

Step 8 − 각 작업의 기간을 추정합니다.

광대역 델파이 기술

Wideband Delphi Method에서 WBS는 작업 재평가를 위해 3-7 명의 구성원으로 구성된 팀에 배포됩니다. 최종 추정치는 팀 합의를 기반으로 요약 된 추정치의 결과입니다.

이 방법은 통계적 공식보다는 경험에 대해 더 많이 말합니다. 이 방법은 그룹 반복을 강조하기 위해 Barry Boehm에 의해 대중화되어 팀이 테스트 노력을 추정하면서 문제의 다양한 측면을 시각화 한 합의에 도달했습니다.

기능 포인트 / 테스트 포인트 분석

FP는 사용자 관점에서 소프트웨어 응용 프로그램의 기능을 나타내며 소프트웨어 프로젝트의 크기를 추정하는 기술로 사용됩니다.

테스트에서 추정은 요구 사항 사양 문서 또는 이전에 생성 된 애플리케이션 프로토 타입을 기반으로합니다. 프로젝트의 FP를 계산하려면 몇 가지 주요 구성 요소가 필요합니다. 그들은-

• Unadjusted Data Function Points − i) 내부 파일, ii) 외부 인터페이스

• Unadjusted Transaction Function Points − i) 사용자 입력, ii) 사용자 출력 및 iii) 사용자 문의

• Capers Jones basic formula −

  테스트 케이스 수 = (기능 점수 수) × 1.2

• Total Actual Effort (TAE) −

  (테스트 사례 수) × (개발 노력 백분율 / 100)

백분율 분포

이 기술에서는 SDLC (Software Development Life Cycle)의 모든 단계에 노력이 %로 할당됩니다. 이는 유사한 프로젝트의 과거 데이터를 기반으로 할 수 있습니다. 예를 들면-

단계	노력의 %
프로젝트 관리	7 %
요구 사항	9 %
디자인	16 %
코딩	26 %
테스트 (모든 테스트 단계)	27 %
선적 서류 비치	9 %
설치 및 교육	6 %

다음으로, 테스트를위한 노력의 % (모든 테스트 단계)는 모든 테스트 단계에 대해 추가로 분배됩니다.

모든 테스트 단계	노력의 %
구성 요소 테스트	16
독립 테스트	84
Total	100

독립 테스트	노력의 %
통합 테스트	24
시스템 테스트	52
수락 테스트	24
Total	100

시스템 테스트	노력의 %
기능 시스템 테스트	65
비 작동 시스템 테스트	35
Total	100

테스트 계획 및 설계 아키텍처	50 %
검토 단계	50 %

경험 기반 테스트 추정 기법

이 기술은 유추와 전문가를 기반으로합니다. 이 기술은 이전 프로젝트에서 유사한 애플리케이션을 이미 테스트하고 해당 프로젝트에서 메트릭을 수집했다고 가정합니다. 또한 이전 테스트에서 메트릭을 수집했습니다. 애플리케이션 (및 테스트)을 잘 알고있는 주제 전문가의 의견을 듣고 수집 한 메트릭을 사용하여 테스트 노력에 도달하십시오.