IT자격증

EVM (Earned Value Management) 은 일명 '획득가치관리' 로서 어떤 정해진 작업에 대한 일정 및 원가를
수치적으로 관리할 수 있는 관리 기법중에 하나이다.
특히 일정관리와 원가관리를 동시에 할 수 있도록 고안된 기법이다.
EVM의 3가지의 Value 에 의해서 표현이 되는데 다음과 같다.

 ① PV (Planned Value) 
       -  계획가치
       - BCWS (Budgeted Cost of Work Schedule)
       - 계획된 스케쥴에 의한 할당된 예산
       - 초기계획에서 일정에 따른 계획된 작업의 가치
          ▶ 즉 해야할 작업의 양을 나타낸다. 

  ② EV (Earned Value)
        - 획득가치
        - BCWP (Budgeted Cost of Work Performed)
        - 수행된 작업에 대한 원래 예산
          ▶ 즉 실제 완료된 작업의 양을 나타낸다.

  ③ AC (Actual Cost)
        - 실제비용
        - ACWP (Actual Cost of Work Performed)
        - 수행된 작업에 대한 실제 발생 비용
         ▶ 즉 실제 완료된 작업에 소요된 비용을 나타낸다.

예를 들면.. 10층 건물을 건축하는 작업에서 10일에 한층씩 공사를 완료하기로 하고, 한층 공사비를 1억으로
책정을 하고 계약을 맺었다. 그런데 실제 공사진행상황을 보니깐 10일이 지난 현재 공사는 90% 진행되었고
지금까지 공사비는 1억이 소요되었다라고 하면,
    PV = 1억     <- 원래 10일동안에 완료하기로 한 작업의 양은 한층 , 즉 금액으로 1억
    EV = 0.9억   <- 실제 10일동안에 완료한 작업의 양은 90% 진도율밖에 못나갔으므로 1억 x 0.9 = 0.9억
    AC = 1억     <- 90% 진도율 나가는데 투입된 실제 공사비이므로 1억.. 
                         (당연히 EV가 1억이 되는 시점에는 AC는 1억을 초과할 테니깐.. 결국 PV 1억보다 초과하
                          므로 예산을 초과한 결과를 보일 것이다.)

결국 납기일도 못맞췄고 공사비도 초과 발생한 셈이다.
이 수치를 통해서 앞으로 남은 아홉 층을 공사하는데에 완료예정일 및 소요비용을 예측할수 있으므로 완료예정일
을 납기일에 맞추기 위해 조치를 한다던가, 비용을 당초 예산에 맞추기 위해 어떤 방안을 강구한다던가 
하는 프로젝트 진행에 의사결정의 수단으로 활용할 수 있는게 EVM 이다.


1) EVM에 의한 일정관리

    ① SV  (Schedule Variance / 일정차이)  = EV - PV
                                                       = 0.9 - 1 
                                                       = (-) 0.1 억    ▶ (-) 이면 일정지연을 뜻함
                           
    ② SPI (Schedule Performance Index / 일정성과지수) = EV / PV
                                                                         = 0.9 / 1    ▶ 1 보다 작으면 일정지연
                                                                 

2) EVM에 의한 원가관리

    ① CV (Cost Variance / 비용차이) = EV - AC
                                              = 0.9 - 1 
                                              = (-) 0.1 억    ▶ (-) 이면 예산초과를 뜻함

    ② CPI (Cost Performance Index / 원가성과지수) = EV / AC
                                                                  = 0.9 / 1 
                                                                  = 0.9 ▶ 1 보다 작으면 예산초과

    ③ BAC (Budget At Completion / 실행예산) = 당초 완료하는데 계획된 총예산 
                                                             = 10억  (한층에 1억씩 총 10층 건축)
    
    ④ EAC (Estimate At Completion / 현시점에서 예상되는 종료시의 최종 비용)
                   = BAC/CPI
                   = 10억 / 0.9
                   = 약 11억    ▶ 현재 CPI 지수 0.9 가 그대로 끝까지 유지된다면 결국 비용이 예산을
                                       약 1억 초과한 11억이 발생할 것으로 추정됨을 뜻함
     
    ⑤ ETC (Estimate To Completion
              /현시점까지 이미 투입된 비용(AC) 를 제외하고 앞으로 종료시까지 투입이 예상되는  비용 )
                    = EAC - AC
                    = 11 - 1 
                    = 10 억  ▶ 지금부터 앞으로 투입될 예상비용을 뜻함
 
    ⑥ VAC (Variance At Completion / 예산대비 실제실적 차이)
                    = BAC - EAC
                    = 10 - 11
                    = (-) 1억  ▶ (-) 이면 예산초과가 예상됨을 뜻함

   ⑦ TCPI (To-Complete Performance Index / 소요작업효율)
                    =  남은 작업량 / 남은 예산
                    = (BAC-EV) / (BAC-AC)
                    = (10 - 0.9) / (10 - 1)
                    = 9.1 / 9
                    = 1.01  ▶ 1 보다 크면 남은 예산에 비해서 해야할 작업이 많다는 뜻.. (비효율)

EVM (Earned Value Management)

EVM (Earned Value Management) 은 일명 '획득가치관리' 로서 어떤 정해진 작업에 대한 일정 및 원가를
수치적으로 관리할 수 있는 관리 기법중에 하나이다.
특히 일정관리와 원가관리를 동시에 할 수 있도록 고안된 기법이다.
EVM의 3가지의 Value 에 의해서 표현이 되는데 다음과 같다.

 ① PV (Planned Value) 
       -  계획가치
       - BCWS (Budgeted Cost of Work Schedule)
       - 계획된 스케쥴에 의한 할당된 예산
       - 초기계획에서 일정에 따른 계획된 작업의 가치
          ▶ 즉 해야할 작업의 양을 나타낸다. 

  ② EV (Earned Value)
        - 획득가치
        - BCWP (Budgeted Cost of Work Performed)
        - 수행된 작업에 대한 원래 예산
          ▶ 즉 실제 완료된 작업의 양을 나타낸다.

  ③ AC (Actual Cost)
        - 실제비용
        - ACWP (Actual Cost of Work Performed)
        - 수행된 작업에 대한 실제 발생 비용
         ▶ 즉 실제 완료된 작업에 소요된 비용을 나타낸다.

예를 들면.. 10층 건물을 건축하는 작업에서 10일에 한층씩 공사를 완료하기로 하고, 한층 공사비를 1억으로
책정을 하고 계약을 맺었다. 그런데 실제 공사진행상황을 보니깐 10일이 지난 현재 공사는 90% 진행되었고
지금까지 공사비는 1억이 소요되었다라고 하면,
    PV = 1억     <- 원래 10일동안에 완료하기로 한 작업의 양은 한층 , 즉 금액으로 1억
    EV = 0.9억   <- 실제 10일동안에 완료한 작업의 양은 90% 진도율밖에 못나갔으므로 1억 x 0.9 = 0.9억
    AC = 1억     <- 90% 진도율 나가는데 투입된 실제 공사비이므로 1억.. 
                         (당연히 EV가 1억이 되는 시점에는 AC는 1억을 초과할 테니깐.. 결국 PV 1억보다 초과하
                          므로 예산을 초과한 결과를 보일 것이다.)

결국 납기일도 못맞췄고 공사비도 초과 발생한 셈이다.
이 수치를 통해서 앞으로 남은 아홉 층을 공사하는데에 완료예정일 및 소요비용을 예측할수 있으므로 완료예정일
을 납기일에 맞추기 위해 조치를 한다던가, 비용을 당초 예산에 맞추기 위해 어떤 방안을 강구한다던가 
하는 프로젝트 진행에 의사결정의 수단으로 활용할 수 있는게 EVM 이다.

Burn Down Chart (소멸차트)

Burn Down Chart 는 남아 있는 일(work)의 양과 시간(time) 사이의 관계를 그래픽으로 표현한 2차원적인 차트이다.
Run chart (런차트)라고 불리며 일반적으로 Agile 에서 사용된다. 
Agile 관리의 핵심이 반복되는 짧은 주기의 작업이 핵심이기 때문에 그 작업단위의 진도 체크 (tracking daily progress)
이 Agile 프로젝트 관리에 있어서 중요할 수 밖에 없다. 그러한 진도체크의 수단으로 이 Burn Down Chart 를 많이
사용한다. Burn Down 의 의미가 소멸된다는 의미로서 해야할 작업. 즉 남아 있는 일의 양이 줄어드는 것을 차트로
표현 한 것이다. Burn Down Chart 를 보면 모든 작업이 완료되었을 때 모든 작업이 소진(Burn Down) 되어 0 으로
수렴하는 모양을 나타낸다. 

에자일(Agile) 개발방법론의 종류에는 여러가지가 있지만 그중에서도 XP와 SCRUM이 제일 많이 통용된다
두 방법은 어떤 잛은 주기의 개발기간과 개발내용을 반복적으로 수행하는 측면에서는 동일하다.

XP (Extreme Programming) 의 등장배경과 정의

개발을 하기위해 사용자로부터 요구사항을 듣고 분석및 설계의 바탕이 되는 요구사항을 정의해야 하는데
실제 요구사항의 분석이 쉽지는 않다. 또한 사용자 입자에서도 자기가 원하는 요구사항을 명확하게
생각해내서 제시하는 것 또한 어려운 상황이다. 어리다 보니 불필요한 다량의 문서작업으로 인해 개발자의
의욕을 저하시키게 된다.
그래서 사용자의 요구사항을 한꺼번에 받는 방식이 아닌 반복형 모델의 개발주기를 극단적으로 짧게
함으로써 프로그래머가 설계,구현,시험 활동을 전체 SW개발기간에 걸쳐 조금씩 자주 실시하도록 하는 
개발방법이 XP (Extreme Programming)  이다. 

XP (Extreme Programming) 의 특징

  ① 짧은 개발주기 반복
  ② 프로토타입이 일찍 자주 만들어짐
  ③ 개발계획이 프로젝트 진행동안 계속 변화됨


XP (Extreme Programming) 의 4원칙

XP (Extreme Programming) 의 12가지 기본원리

SCRUM 

XP와 SCRUM 비교

에자일(Agile) 개발 방법론의 탄생 배경

보통 소프트웨어를 개발하는 과정을 보면 우선 사용자로부터 요구사항수집을 해서 분석을 하고
설계를 하고 개발하고 테스트를 해서 최종 Release 하는 방식으로 전통적인 방식이다.
일명 '폭포수(Waterfall)' 방식이라고 하는데  가장 많이 사용되는 개발방법이다.
이 전통적인 폭포수 개발 기법이 지닌 단점은 지나치게 계획과 절차에 의존한다는 것이다. 각 단계별로 
완료가 되어야 다음 단계로 넘어갈 수 있다. 물론 각 단계에 걸쳐 제어의 증가가 가능하지만, 이미 계획과
절차가 고정되어 있기 때문에 중간에 기능이나 프로세스의 변경사항이 발생하면 이를 반영하기가 어려운
개발방법론중에 하나다 . 즉 프로젝트가 이미 진행 중인 상황에서 프로젝트 범위가 변경될 때 유연성이 극히 떨어진다
또한 빈틈없는 계획과 단계별 엄격한 심사(Gate Review)를 중시하다 보면 당연히 시간과 비용의 낭비가 증가하게 된다.
하나의 오류가 발생하면 이를 해결하기 위해 이전 단계로 거슬러 올라가서 다시 내려와야 하기 때문에 납기일 준수가
쉽지 않게 된다.  소프트웨어 개발 업계에서 관행화된 납기일 지연과 반복되는 야근, 그리고 이에 따른 스트레스로 개발자들의 번아웃(Burn-out)이 빈번하게 발생하는 것도 이와 무관치 않다.
애자일 방식은 이런 단점을 개선할 수 있다는 기대를 받으며 1990년대에 처음 등장하였다.
대표적으로 Microsoft사의 익스플로러 개발에 적용을 해서 성공한 걸로 이름이 알려지기 시작했다. 
Microsoft사는 그 다시 웹브라우저 시장을 장악하고 있던 넷스케이프를 이기기 위해 Internet Explorer 개발
프로젝트를 가동했는데 이때 Agile 방식을 적용했다. 즉 전체 요구사항의 30% 정도 개발된 알파 버전을 공개했고
그 이후 feedback 을 수용해서 50% 정도 개발된 버전을 공개하였다.. 이런 식으로 feedback과 공개를 반복해가면서
프로젝트를 진행해.. 결국 대성공을 거두었다.

에자일 (Agile) 의 정의

Agile 이란 단어의 뜻은 '민첩한' 이라는 뜻이다. 먼가 개발을 민첩하게 한다는 뜻이겠지요..
Agile 방법론이란 짧은 단위로 개발계획을 세워서 개발을 진행해서 Relase 한 후 고객의 Feedback을
받아서 바로 다음 개발계획에 적용나가는 Cycle을 반복함으로써 고객의 요구사항 변화에 신속하고
유연하게 대처할 수 있는 개발 방법론이다.
전통적인 폭포수(Waterfall) 모델은 개발이 다 끝나야 고객에게 시제품을 보여 줄수 있기 때문에
고객의 요구사항 변경에 대응을 바로 못하지만, 에자일(Agile)은 개발단위를 짧게 (보통 1~2주) 잡음
으로써 고객은 바로 시제품을 보고 feedback을 줄 수 있어서 변경사항을 반영하기가 수월하다. 
예를 들면.. 요리사가 레시피를 보고 그대로 요리를 한 후 손님에게 가져다 주는 방식이 폭포수모델
이라고 한다면, 에자일모델은 요리사가 요리를 하면서 중간중간 맛을 보면서 요리를 하는 방식이라고
할수있다.. (적절한 비유인가요?? ㅋㅋ)

에자일(Agile)의 선언

  ① 프로세스/도구보다는  -> 개인과의 소통을 더 중요시
  ② 문서 보다는              -> 동작하는 S/W을 더 중요시
  ③ 계약/협상 보다는       -> 고객과의 협력을 더 중요시 
  ④ 계약준수 보다는        -> 변화에 대응을 더 중요시


에자일(Agile) 개발방법론의 특징

 ① Predictive 하기 보다는 Adaptive 한 방법론  (변화에 반응하는 것이 계획을 준수하는 것보다 우선함)  
 ② 프로세스 중심이 아닌 사람중심의 방법론  (개인간의 의사소통이 프로세스나 도구보다 우선함)
 ③ 동작하는 소프트웨어가 포괄적인 문서보다 우선함.
 ④ 고객과의 협력이 계약협상보다 우선함.


에자일(Agile) 개발방법론의 종류

에자일(Agile) 개발방법론의 단점

에자일 방법론은 현재 대세로 자리 잡고 있는 개발방법론에는 틀림이 없다.
① 하지만 필드에서는 인식이 그렇게 좋은 편은 아니다.. '무한수정방법론' 이라고도 불리울 정도로
    자칫 고객의 요구사항을 계속 반영하다보면은 계속 수정을 할수밖에 없는 상황에 내몰리게 된다
    PM (Projecct Manager)가 적당한 선에서 요구사항을 짤를껀 짤라줘야 하는 , 즉 PM의 역할에 따라
    일의 양이 달라질 수 있다.
② 계획대로 짧은 주기의 작업이 완료될려면 팀원의 능력이 그 만큼 따라주어야 한다. 
    팀내 팀원들의 능력이 같이 않기 때문에 한 팀원의 performance  에 따라 전체 개발기간이 좌우
    될 수있다.. A 팀원의 능력이 1.5 이고 B팀원의 능력이 0.5  이면 전체 능력은 0.5에 맞춰질 수
    있기 때문이다  따라서 팀내의 역량이 부족하다 싶을때에는 매뉴얼화와 그것을 지속적으로 가르쳐줄 수
    있는 시스템이 우선되어야 한다. 그래서 충분히 역량을 발휘하기 좋은 시점이 올때 에자일방식 진행을
    시도하는것이 좋다. 

기능점수 1탄, 2탄 에서는  기능점수(Function Point)의 정의 및 계산방식에 대해서 설명했다.
이번 장에서는 기능 점수를 계산하는 실제 사례를 설명하겠다.
우선 FTR , DET 에 대한 개념에 대해서 설명하고자 한다.

기능점수 측정유형

< 실제 계산 문제 >
   미조정기능점수 (UFP)  : 100
   개선전 조정인자 (VAFB) : 1.02
   추가된 기능점수 (ADD)  : 25
   삭제된 기능점수 (DEL)  : 20
   변경된 기능점수 (CHGB = CHGA 로 간주) : 15
   변경후 조정인자  : 1.05

1) 개선이후 조정된 기능점수 값은 얼마인가 ?
 - 개선이후 최종 Application의 기능점수를 말한다.
   즉, AFP = [(기존기능 + 추가된 기능 + 변경후 기능) - (변경전 기능 + 삭제된 기능)] x 변경후 조정인자
              = [(UFP + ADD + CHGA) - (CHGB + DEL)] x VAFA 
              = [(100 + 25 + 15) - (15 + 20)] x 1.05 

2) 개선기능점수는 얼마인가?
 - 개선된 부분에 대한 점수
   즉, EFP = [(추가된 기능 + 변경후 기능) x 변경후 조정인자 - (삭제된 기능)x변경전 조정인자] 
              = [(ADD + CHGA)xVAFA - ( DEL)] x VAFB 
             =  [(25 + 15) x 1.05 - (20) x 1.02]  

기능점수 (Function Point) 의 정의

기능점수(Function Point)는 소프트웨어의 양과 질을 동시에 고려한 소프트웨어 규모산정 방식의 일종으로 
정보처리규모와 기능적 복잡도에 의해 소프트웨어 규모를 사용자의 관점에서 기술적요소는  배제하고 
측정하는 방식

기능점수 (Function Point) 의 특징

 - 최종사용자 입장에서 소프트웨어의 규모를 견적하는 값임
 - 프로젝트 완료 후 생산성 평가를 위해 개발되었으나 사전에 개발소요공수를 예측하는 모델
   로도 사용가능.
 - 개발환경과 기술에 무관하게 측정가능하고 사용자의 요구에 따라 시스템 기능 설계시 개발
   중에도 측정 가능함.
 - 생산성과 품질 척도로도 활용 가능.


기능점수 (Function Point) 계산 순서

기능점수 (Function Point) 계산 구성 요소

14개 기술 복잡도 항목

1 데이터 통신    2.분산데이터처리   3.처리복잡도     4.자원제약정도
5.시스템성능     6.트랜잭션비율      7.온라인데이터입력   8.온라인갱신
9.설치용이성     10.운영용이성        11.변경용이성
12.다중설치서    13.재사용성        14.최종사용자효율성


기능 유형별 평균 복잡도 순위

내부논리파일(LIF) > 외부연계파일(EIF) > 외부출력(EO) > 외부입력(EI) > 외부조회(EQ)


기능점수 (Function Point) 의 주요 용어들 정리

기능점수 (Function Point) 의 정의

기능점수(Function Foint)의 가장 큰 특징은 소프트웨어의 규모를 산정할 때 개발자 즉 공급자 입장이
아닌 사용자 입장에서 그 규모를 산정한다는 점이다.
즉 사용자의 업무적 요구사항에 대해 소프트웨어가 제공하는 소프트웨어의 기능을 논리적 관점에서
식별하여 사용자 관점에서 소프트웨어의 규모를 측정하는 방법.
쉽계 말하면 화면 단위로 각 화면에서 제공하는 기능 (조회,입력,저장,수정...)에 대해서 기능 유형별 
수량과 성능 및 품질요인들의 영향도를 고려하여 소프트웨어의 규모를 측정하는 방법


기능점수 (Function Point) 의 특징

① 소프트웨어가 사용자에게 제공하는 기능적 요구사항을 측정한다. 
② 기능점수는 “소프트웨어가 어떻게 구현되었는지”의 공급자 관점이 아니라 “사용자가 어떠한 기능을
    요구했는지”의 수요자 관점에서 측정
③ 개발 이전에 업무량을 측정 가능
④ 개발은 물론 기획, 운영 등 전 수명주기에 걸쳐서 측정 가능
⑤ 소프트웨어 개발 및 유지관리의 업무량을 조직, 구현기술, 공수, 적용방법론, 물리적 또는 기술적
   컴포넌트와 무관하게 일관성 있게 측정 가능


기능점수 산정방식의 종류

소프트웨어 개발비의 구성요소

소프트웨어 개발비 산정 시 주요 요소는 = 개발원가 + 직접경비 + 이윤 이다. 
① 개발원가는 소프트웨어 개발규모를 우선 산정 한 후 이를 토대ㅗ 보정전 개발원가를 계산한다.
    그런다음 거기에대가 보정계수를 고려한 개발원가를 산출한다.
② 직접경비는 개발에 직접 투입된 비용들 
③ 이윤은 개발원가 의 25% 이내로 한다.

5가지 보정원가 계수

소프트웨어 규모산정의 필요성

소프트웨어를 자체개발하던지 아니면 외주를 줘서 개발하던지 개발하고자 하는 소프트웨어의
규모를 대충 알아야 개발기간 및 공수산정을 할 수 있으며, 외부개발인 경우 과연 얼마의 돈을
주고 개발을 해달라고 하는게 맞는건지 측정기준이 있어야 할것이다. 그래야 개발을 요청하는
발주사나 개발을 수행할 SI공급사나 서로 통일된 기준으로 비용과 원가를 산정해서 계약서에
금액을 명시 할 수 있을 것이다.
과거에는 그냥 SI공급사가 제안한 턴키 금액을 가지고 대충 업체 선정하고 했지만 지금은
'SW사업대가 산정기준" 등 정부에서 기준을 마련해서 공공기관 사업부터 적용하고 있다.
오늘은 소프트웨어 규모를 산정하는 방법에는 머가 있는 지 알아보고, 다음 편에서는 대표적인
소프트웨어 산정기준은 기능점수(Function Pointy) 에 대해서 1,2부로 나누어서 자세히 알아보고
자 한다. (Function Point 만 대충 설명할려고 해도 거의 책 한권의 분량이다.)


소프트웨어 규모산정 방법들..

양적 규모산정 방식 - LOC방식

양 과 질을 고려한 방식

COCOMO 종류

 1.Basic COCOMO - S/W 개발노력과 비용을 LOC형태로 추정한 후 비용을 산정하는 단일값 모형 
                              (Static Single-Value model)
                          - 제안단계에서 사용
          ① Organic            - MIS, 50KDSI (50,000라인)
          ② Semi-detachedd - Compliler, 개발지원도구 개발 , 300KDSI
          ③ Embeded           - OS, DBMS,통신모티너  , 대형프로젝트

2.Intermediate COCOMO - 15개 특성치 적용한 방식
          ① 제품속성(3개)             - S/W신뢰도, DB크기, 제품복잡도
          ② H/W속성(컴퓨터)(4개) - 응답시간, 실행시간 성능제약, 기억장치제약, 가상기계 환경의 휘발성
          ③ 인적속성(5개)             - 분석가능력, 응용의 경험, 언어구사경험, S/W공학자능력, 가상기계에대한 경험
          ④ 프로젝트 속성(3개)     - 일정, 개발도구사용, 방법론 응용

3.Detailed COCOMO - 대형인 경우 Sub시스템으로 쪼개서 별도 산정한 후 합산하는 방식
          ① 모듈레벨
          ② 서브시스템 레벨
          ③ 시스템 레벨 


COCOMO II

1단계 : 프로토타입 만드는 단계  -> Application Point 계산해서 노력 추정  -> 응용결합모델
2단계 : 초기설계단계          -> FP 사용 -> 초기설계모듈
3단계 : 구조설계 이후 단계  -> FP 와 LOC를 규모척도로 해서 Reuse, Post Architecture  
                                     -> 포스트 아키텍쳐 모델        

1. 응용결합모델 (Application Composition Model)
     - 작은팀이 몇주의 기간동안 개발하는 경우에 사용, 주로 GUI Builder 나 컴포넌트들을 이용하여 조립 개발하는
        경우
     - 스크립트, DB, 프로그래밍을 이용하여 개발된 프로토타입시스템
     - 객체점수의수
2. 초기설계모듈 (the Early Design Model )
     - 비교적 개발 초기단계에 사용되어지며 실제 개발할 SW의크기 . 운영환경의 특성, 프로젝트에 참여할 관련자
      , 수행할 프로세스의 세부사항 등에 대한 정보가 부족할 때 사용
     - 시스템 요구사항과 설계선택방안에 기반을 둔 초기 비용 산정
     - Function Point 의 수
3. 재사용 모델  
     - 재사용가능한 컴포넌트 혹은 자동적으로 생성되는 코드를 통합하기 위한 노력
     - 재사용되거나 생산된 라인수
4. 포스트 아키텍쳐 모델 (Post Architecture Model)
     - 가장 세부적인 모델로 SW생명주기가 확립된 후에 사용하며, 소프트웨어를 개발하여 유지보수 하는 동안 사용
     - 시스템 설계명세화에 기반한 개발노력
     - 소스코드 라인의 수