728x90
반응형
SMALL

디지털 트윈(Digital Twin)  의 개념

디지털 트윈 (Digital Twin) 이란 가상공간에 현실세계의 실물,시스템,환경 등과 똑같은 쌍둥이(Twin) 을
만들어서다양한 모의실험 및 시뮬레이션을 수행함으로써 미리 기술과 효과를 검증해 보는 기술을 말한다.
영화에 보면 비행기 조정사들이 실제 비행기를 조정하지 않고 시뮬레이션을 통해 연습을 하는 장면이
나오는데 그런 개념과 비슷하다고 볼수 있다.
하지만 디지털 트윈은 단순한 가상세계를 독립적으로 만드는 개념보다는 한발짝 더 나아가서 실제 대상에 
센서를 달아서 상태정보를 바로바로 트윈 가상세계에 반영함으로써 현실세계와 조건을 똑같이 동기화
시킴으로서 다양한 환경에 대한 영향도 파악및 기기 고장을 예측할 수 있는 시스템이다.
따라서 사물인터넷(IoT)와 밀접한 관계를 가질 수 밖에 없다. 
미국 가전업체인 제너럴 일렉트릭(GE)이 주창한 개념으로 2000년대 들어 제조업에 도입되기 시작했으며
항공, 건설, 헬스케어, 에너지, 국방, 도시설계 등 다양한 분야에서도 활용되고 있다. 예를 들어 항공기가
비행하면서 겪게 되는 환경 정보를 수집해 디지털 트윈에 적용하면 환경이 항공기에 미치는 영향을 파악하고
기기 고장을 예측할 수 있다.  (참고 : 네이버 지식백과)

디지털 트윈(Digital Twin) 의 장점

디지털 트윈 기술을 활용하면 가상세계에서 장비, 시스템 등의 상태를 모니터링하고 유지·보수 시점을 파악해
개선할 수 있다. 가동 중 발생할 수 있는 다양한 상황을 예측해 안전을 검증하거나 돌발 사고를 예방해 사고
위험을 줄일 수도 있다. 또한 생산성 향상, 장비 최적화 등의 결과를 가져올 수 있고 시제품 제작에 들어가는
비용과 시간을 대폭 절감할 수 있다.  (
[네이버 지식백과] 디지털 트윈 (시사상식사전, pmg 지식엔진연구소))

디지털 트윈(Digital Twin) 의 모델 사례

그림 1의 모델을 구성하는 구성 요소들은 다음과 같이 설명된다.

구성요소 설명
센서 제조공정 전반에 걸쳐 배치된 센서들이 실세계의 물리적 프로세스에 대한 운영 및 환경 정보를 포착하는 신호를 생성
데이터 센서에서 생성된 실제 세계의 운영 및 환경 데이터는 기업의 다른 데이터들과 결합되어 
종합되는데, 기타 데이터에는 자재명세서(bill of material), 기업 시스템 정보, 설계 시방서
,
 엔지니어링 도안, 외부 데이터 피드 연결정보, 고객 불만사항 등이 존재
종합 센서는 종합 기술(통신 인터페이스, 보안 기술 등 포함)을 통해 물리적 세계와 디지털 
세계 간의 데이터 전송을 수행. 
애널리틱스 애널리틱스 기법은 알고리즘 기반의 시뮬레이션과 시각화 루틴을 통해 데이터를 분석하는 데 사용되어 인사이트를 생성. 
디지털 트윈 그림 1의 ‘디지털’ 부분이 디지털 트윈이며, 앞의 구성 요소들을 결합해 물리적 세계 및 프로세스를 거의 실시간에 가까운 디지털 모델로 생성. 모델의 목표는 최적값에서 벗어나는 허용 불가능한 오차를 다양한 차원에 걸쳐 파악하는 것. 즉, 이러한 오차의 분석을 통해 비용 절감, 품질 개선, 높은 효율성 달성 등의 기회를 파악. 분석 결과는 물리적 세계에서의 행동으로 이어질 수 있음. 
작동장치 실제 세계에서의 대응을 위해, 디지털 트윈은 작동장치를 통한 행동 절차를 생성. 작동장치는 물리적 프로세스의 동작을 유발하는 인간의 개입에 의해 통제됨.
그림 1의 모델은 제품 라이프사이클 중 제조과정에 초점을 맞춘 디지털 트윈의 단지 한
가지 모습에 불과하다. 하지만 이 모델은 물리적 세계와 디지털 세계의 연결이 가진 총체적, 통합적, 반복적 특성을 보여준다.

< 출처 : Deloitte Anjin Review | No.9 -  "인더스트리 4.0과 디지털 트윈 제조업이 천생연분을 만나다" >


디지털 트윈(Digital Twin) 의 구축 기술

구분 구축기술 상세
스마트시티의
현실세계
정보수집
Sensor 이용한 Agent 
활용 기술
이미지, 음향, 근접, 조도, 가속도, 자이로스코프, 동작인식, 온도/습도, 기 압, 제스처 센서장비 이용한 지능형 Agent 활용
IoT(Internet of Things) 
컨트롤러와 통신
WPAN, PLC, Modbus, RS-232, 485, PLC 등 다양한 산업 프로토콜 이용 제어기와 NB-IoT, LoRa 저전력 통신 수집
스마트시티
가상세계
모델링
시뮬레이션 모델링 - 수학적 모델 표현 어려운 시스템을 모의실험 통해 분석하는
  모델링
- 미분방정식을 통한 연속모델링과 시간별 샘플링 추상화한 
  이산모델링
수학적 및 3D 모델링 행위기준 수학적 모델링과, 이산모델 기반 가상환경 모델링
스마트시티의
데이터
저장&분석
클라우드 분산컴퓨팅, 가상화 등 활용 정형, 비정형 데이터 저장
인공지능 지도학습, 비지도학습, 딥러닝 기술 등을 활용하여 데이터 분석 및 예측
시티 내,외부간
상호작용
Actuator 연결 제어 분석 된 데이터를 현실세계의 동력 생산 기계인 Actuator 전달
디지털 스레드 디자인/분석/시뮬레이션, 제작 및 모니터링, 테스트 및 검증
, 출하 및 유지보수가 하나의 공정으로 연결
728x90
반응형
LIST

'디지털서비스' 카테고리의 다른 글

IPS (Indoor Positioning System)  (0) 2019.10.17
LBS (Location Based Service) 측위 기술  (0) 2019.10.16
R 과 Python 의 비교  (0) 2019.09.25
머클트리(Merkle Tree)  (0) 2019.09.19
Data Lake - 데이터 단일 저장소  (0) 2019.09.09
728x90
반응형
SMALL

블록체인을 보안강화를 위해 도입을 하지만 또 반대로 블록체인을 도입시에 블록체인 자체에 대한
보안 위협이 존재한다. 
2017년 8월 17일 금융보안원에서 발표한 [블록체인 기술과 보안 고려사항] 을 기반으로 블록체인
도입시 고려해야 할 보안위협및 그 대책에 대해서 알아보고자 한다.

블록체인 도입 시 보안위협

금융권에서 블록체인 도입 시 고려가 필요한 보안위협을 아래 5가지로ㅗ 분류했다.
  (1) 키 관리, (2) 거래 검증 및 합의, (3) 참여자 권한관리, (4) 블록체인 S/W 보안, (5) 서비스 보안

분류 보안위협 설명
키 관리 키 도난 및 분실 공격자에게 키를 도난당하거나 분실된 키가 악용될 경우 자산 및 기밀거래 메시지 유출
취약한 키 생성 취약한 키 생성 알고리즘으로 인해 키 재생성 공격이 가능할 경우 자산 및 기밀거래 메시지가 유출 가능
거래 검증 및 
합의
합의 가로채기 참여자 중 과반수(또는 운영주체)를 장악하여 블록체인의 합의 과정을 조작
사이드 체인 내 비정상
거래 발생
메인 체인에서 유효하지 않은 자산이 사이드 체인에서 거래 가능
참여자
권한관리
개인정보 침해 거래정보에 대한 참여자의 접근권한 관리 부족시
개인정보 침해 가능
권한 오남용 참여자의 내·외부 권한관리 부족시 금융회사 및 내부직원에 의한 보안사고 등 발생 가능
블록체인 S/W
보안
블록체인 S/W 취약점 블록체인 S/W에 보안 취약점이 존재할 경우 키 도난, 합의 조작, DDoS 공격 등에 악용가능
스마트 컨트랙트 취약점 스마트 컨트랙트에 취약점이 존재할 경우 자산유출, 개인정보 침해, DDoS 공격 등에 악용가능
서비스
보안
분산 서비스 거부 공격 분산 서비스 거부 공격분산 서비스 거부 공격다수 참여자가 악성코드 등을 통해 공격자에게
장악될 경우 대량의 스팸거래를 발생 가능하며
이로 인해 블록체인 서비스가 중단 가능
가용성 저하 블록체인의 처리속도 한계, 거래정보 급증으로
인해 추가 서비스 개발 및 확대 제한 등의
가용성이 저하
비정상거래 탐지 불가 비정상거래에 대한 사전 탐지 및 차단 기술이
부족하여 사기거래, 자금세탁, 이중지불 등의
거래가 발생 가능
상호운용성 미제공 블록체인 간 자산교환, 기능 확장 등 연계 필요시
책임주체 및 표준규격이 명확하지 않아 예상치
못한 보안위협 발생 가능


* 사이드 체인 (SideChain) 이란 ?
    비트코인(bitcoin)의 탄생은 획기적이기는 하지만 모든 최초 탄생이 그랬듯이 고유한 한계점을 가지고 있다.
    <한계점>
        ① 속도가 느리다
        ② 오직 비트코인 블록체인 위에서는 오직 비트코인 만이 이체가 가능하다. 따라서 이종화폐와
            교환할려면 결국 중앙화된 웹거래소를 이용해야하는데 이는 결국 블록체인이 가진 보안적
           ,탈중앙화적 이점을 부정하는 셈이 된다.
        ③ 비트코인 블록체인에서 사용할 수 있는 기능이 제한적이다.
        ④ 비트코인은 로직을 수정하기에는 감담이 안된다.. 
        ⑤ 비트코인 상에서 일어나는 모든 거래는 기밀이 유지 안된다.

  <한계점을 극복하고자 고안한 것이 바로 사이드 체인>
     이러한 한계점을 갖고 있는 비트코인이지만 그렇다고 비트코인을 안 쓸수는 없다. 왜냐 암호화폐계
     의 기준통화나 다름 없기 때문이다. 따라서 생각해 낸것이 바로 비트코인을 다른 블록체인에서
     거래를 하는 방법이다.
      비트코인이 이더리움 블록체인에 올라갈 수 있다면, 다양한 스마트 컨트랙트(Smart Contract)나 탈중앙화
     어플리케이션(DApp)에서 사용될 수 있을 것이다. 비트코인의 속도가 걱정이 된다면, 속도가 빠른 다른
     블록체인에 비트코인을 올려서 사용하면 될 것이고 응용성을 원한다면 이더리움(Ethereum)에, 기밀성을
     원한다면 대쉬코인(Dashcoin) 등의 블록체인에 올려서 거래를 하면 될 것이다. 
     비트코인의 소유자가 해당 코인을 이더리움 블록체인 위에 올려서 거래하고자 할 경우, 비트코인 블록체인에
     있는 비트코인을 '동결(Freeze)'시키고 이더리움 블록체인 위에서 이 비트코인에 해당하는
     '상응물(counterpart)'을 만들어 거래할 수 있도록 하는 것이다. 이후 거래된 '상응물'의 소유자는 비트코인
     블록체인에 있는 진짜 비트코인으로 이 상응물을 교환해 갈 수 있다.
      즉, 비트코인 블록체인의 비트코인을 동결하고, 이에 상응하는 코인을 사이드체인에 생성해서, 사이드체인
     위에서 사이드체인의 혜택을 누리며 거래를 하고, 이를 마치면 다시 해당 상을물로 비트코인 블록체인의
     비트코인을 수령하는 것이다. (위의 경우 이더리움이 곧 사이드체인이 되는 셈이다)      

 


블록체인 도입시 보안위협에 대한 대응방안

< 출처 : 정보관리기술사 118회 모임 - 두드림 >

 

728x90
반응형
LIST
728x90
반응형
SMALL

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 그래프

 

728x90
반응형
LIST
728x90
반응형
SMALL

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 이다.

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 으로
수렴하는 모양을 나타낸다. 

< 출처 : https://blog.naver.com/laster40/55492369 >

 

Burn Down Chart 8요소

 

  EVM  Burn Down Chart
개념 작업의 일정과 비용을 예측해 Risk를
사전에 조치 할 수 있는 관리 기법
업무 대비 시간을 차트기반으로 표현하고
남은 업무를 가시적으로 파악하고 관리하는
기법
용도 전통적 방법론에 주로 활용 에자일 (Agile) 프로젝트에 많이 사용됨
목적 전통적 프로젝트 진척 관리 애자일 (Agile) 프로젝트 진척 관리
범위 프로젝트 공정 전체 기준 실적/계획 진척
관리
Sprint 단위 공정 기준 실적/계획 진척 관리
지표 PV, EV, AC, SV, CV, SPI, CPI
BAC, EAC, VAC, TCPI
수행 기간, 남은 Task추정치
장점 수치화 된 지표를 제공
일정과 비용을 동시에 관리
상태 가시화를 통한 팀 공유 가능
단점 Actual Cost 산정의 어려움  계획작업의 변경 시 유연성 낮음



 

728x90
반응형
LIST
728x90
반응형
SMALL

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

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

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

XP (Extreme Programming) 의 특징

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


XP (Extreme Programming) 의 4원칙

원칙 설명 12가지 기본원리
의사소통
(Communication)
고객과 개발자와의 의사소통을 중요시 User Story 카드
Pair Programming
On site Customer
단순성
(Simplicity)
지금 해야할 일에 대해서 가장 효율적인 디자인이나 코딩을 하는 것이 좋다. Simple Design
Metaphore
피드백
(Feedback)
즉각적인 피드백을 통해 빠른 의사결정
그래서 XP는 항상 코드가 실행가능한 상태유지
On Site Customer
Small Release
Test
Refactoring
용기
(Courage)
 - XP는 개발자들이 자신감있게 변화를 수용 할 수 있도록 그 환경
   을 만들어 준다
- Spike, Small Relase등으로 고객요구사항에 대응하는 용기
Small Release

 

 

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

기본원리 설명
Planning Game 개발계획 수립
 - 고객과 다양한 스토리카드를 통한 개발계획 작성
Small Release 짧은 배포주기
 - 매우 짧은 주기로 모듈 업데이트
Metaphore 문장형태로 시스템 아키텍쳐 기술
공통의 Naming System 개발
고객과 개발자간 의사소통 언어
Pair Programming 개발자 2명이 공동 작업을 한다.
Collective Ownership 공동소유
 - 시스템에 존재하는 코드는 언제 누구든지 수정 가능
Continuous Integration 지속적인 통합
 - 작업이 끝날때마다 지속적으로 통합되고 동시에 테스트 된다
Simple Design 단순설계
 - 현재의 비즈니스 가치에 집중
 - 내일을 고려하는 디자인은 최대한 배제한다.
 - Refactoring 을 통해 개선
Test  - 항상 단위 테스트를 작성한다.
 - TFD (Test First Development) : 테스트 수행 후 검증코드로 작성해  나감
 - 실제 코드를 작성하기 전에 먼저 테스트를 작성해 봄으로써 자신이 무엇을 
   해야하는지 스스로 깨우칠 수 있다.
Refactoring  - 기능변화 없이 중복제거, 단순화, 유연성 추가
 1.Method 정의 - 지나치게 긴 Method 를 분리
                      - 지나치게  긴 문장을 Method를 사용하여 단순화
 2.위치이동 - Method난 변수 위치를 적절한 Class로 이동
 3.캡슐화 - 멤버변수를 Get/Set 사용하여 캡슐화
 4.조건문 단순화 - 긴 조건문을 분할하거나 method 화 하여 단순화
 5.이름변경 - 이해하기 쉬운 이름으로 변경
 6.Indentation - 가독성이 있는 Indent로 재포맷
주40시간 주40시간
On-Site Customer 고객상주
 - 프로젝트팀에 고객이 상주하여 즉각적인 의사소통과 피드백
 - 품질향상의 필수요소
Coding Standard 코드표준을 통한 효과적인 의사소통
 - 자신의 코드에 개발자의 이름, 연락처
 - 주석



SCRUM 

정의 짧은 개발주기에 반복적, 점진적 방법으로 개발  
역할 Scrum Team  - 일정 우선순위에 대한 권한 가짐
 - Product Backlog 에서 Sprint 기간만큼 가져와서 Spring Backlog로
   삼는다.
 - 4~5명 개발자
  Product Owner
(제품책임자/스폰서)
 - Product Backlog 관리
  Scrum Master Owner와 Team간의 의사소통
프로세스 회의 Sprint Planning Meeting 스프린트가 시작할 때 열림다.
회의는 하루종일
모두 참석
Daily Scrum Meeting 15 분 동안 서서
Spring Review Meeting
(with 고객)
 - 한달간의 스프린트를 마쳤을 때 잠재적
   으로 출시가능한 소프트웨어를 고객에
   게 Review 받는다.
 - 가능한한 비공식적
Sprint Retrospective Meeting
(with 팀)
Master와 팀원은 다음 단계에서 개선해야 할 사항 검토
즉흥적인 데모요청을 거부하고 기능구현항목의 동결을 보장받는 대신, 
납기내에 Sprint 목표달성


XP와 SCRUM 비교

  XP SCRUM
형태  - 엔지니어링 방법 초점
 - 프로그램 실천법에 집중
 - Framework는 미포함 (X)
 - 개발 프로세스를 위한 Framework
 - 관리및 조직적 실천법에 집중
 - 특정 엔지니어링 방법 미포함
개발주기 1~2 주 4~6주
변경사항수용 Refactoring을 통한 변경사항 수용
즉 요구사항 변경 발생 인정
Refactoring을 통한 변경사항 수용
즉 요구사항 변경 발생 인정
우선순위 결정 Customer Team
공통점 Agile 방법론으로 짧은 개발주기로 반복 개발




728x90
반응형
LIST
728x90
반응형
SMALL

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

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

<폭포수 (Waterfall) 모델 >


에자일 (Agile) 의 정의

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

< 에자일 (Agil) 모델 >


에자일(Agile)의 선언

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


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

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


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

종류 설명
XP (Exterem Programming) 4가지 가치와 12가지 실천항목. 
테스트강조,  1~3주 Iteration
User Stories, Spike, Test, Iteration
SCRUM 프로젝트를 Sprint 단위로 분리
팀은 매일 Scrum 미팅으로 계획수립 (15분)
DSDM Dynamic Systems Development Method
기능모델 , 설계와구현, 수행 3단계 사이클
영국만 사용
FDD Feature Driven Development
짧은 iteration (2주)
5단계 프로세스 반복


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

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

 

728x90
반응형
LIST
728x90
반응형
SMALL

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

FTR  정보가 실제로 저장되는 논리테이블 개수 (즉 테이블 개수)
외부입력(EI)기능을 수행하는 동안에 참조하는 논리테이블 수
 Ex) 회원등록기능은 사용자마스터테이블에 정보가 저장되므로 FTR = 1
DET 사용자가 입력한 
   - 데이터 정보(Input 필드),  
   - 기능버튼(버튼,라디오,콤보박스), 
   - Message 개수 (에러메시지,확인메시지, 단 Notification Message는 아님)

회원가입화면의 기능점수
외부조회(EQ)


기능점수 측정유형

측정유형 설명
1 개발프로젝트
  기능점수 (DEP)
Development Function Point
개발완료시 프로젝트가 종료된 후 고객에게 최초 인도된 소트프웨어의 기능을 측정
2.개선프로젝트
  기능점수 (EFP)
Enhancement Function Point
사용자가 현재 사용중인 어플리케이션에 변경발생시 추가,수정,삭제한 부분에 대한 기능점수 즉 유지보수한 작업
EFP = [(ADD + CHGA + CFP) * VAF] + (DEL * VAFB)
               
* ADD   : 추가된 기능의 UFP
  CHGA : 수정되는 기능의 UFP
  CFP    : 변환기능의 FP
  DEL    : 삭제되는 기능의 UFP
  VAFA  : 프로젝트 완료 후 VAF(조정인자)
  VAFB  : 프로젝트 시작 전 VAF(조정인자)
3. 어플리케이션
   기능점수(AFP)
Application Function Point
개선요구사항 완료후 현재 상태에서의 기능점수를 재계산
즉, 개선이 발생하면 추가된 기능과 변경된 기능은 최초 고객이 보유했던 기능점수에 더해지고 변경되기전 기능과 삭제된 기능은 반대로 빼서 현재 고객이 보유한 어플리케이션의 기능점수 측정
이는 최초 FP에 개선FP 를 합산한 것과 같다.
즉, 어플리케이션FP = 개발FP + 개선FP 
1) 어플리케이션 패키지를 변경없이 설치 시
   AFP = ADD * VAF

2) 애플리케이션 패키지를 변경하여 설치시 
  AFP = [ ( UFPB   + ADD    + CHGA)    - ( CHGB     + DEL ) ] * VAFA
             ( 기존FP + 추가FP + 변경후FP) - (변경전FP + 삭제된FP)
        =   기존FP   + 추가FP +   변경으로 증분된 FP   - 삭제된FP
               
* UFPB   : 개선전의 UFP
  CHGA  : 수정되는 기능의 UFP
  CHGB  : 개선전의 수정된 UFP
  VAFA  : 프로젝트 완료 후 VAF(조정인자)
  VAFB  : 프로젝트 시작 전 VAF(조정인자)



< 실제 계산 문제 >
   미조정기능점수 (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]  

728x90
반응형
LIST
728x90
반응형
SMALL

기능점수 (Function Point) 의 정의

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

기능점수 (Function Point) 의 특징

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


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


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

구성요소 설명  
측정유형 ① 개발 FP - 신규 개발 
② 개선 FP - 추가/삭제되는 부분
③ APP FP - 현재 프로그램의 FP  (SLA나 유지보수 공수산정을 위해 측정)

  즉. 개발 FP +  개선 FP = APP FP
데이터 기능측정
= 기능수
= Function Count
정적인 자료의 양으로  ERD에서 도출된다.(what)
  ① ILF - Internal Logical File (내부논리파일)
             측정대상 시스템이 유지,관리하는 데이터의 집합
             통상 파일 또는 데이터베이스를 말함.
  
  ② EIF - External Interface File (외부인터페이스파일)
             측정대상 시스템이 참조하는 타시스템의 데이터 집합
             통상 타시스템의 파일 또는 데이터베이스                
DET/RET
트랜잭션기능측정
= 기능수
= Function Count
동적인 표현으로 정적으로 표현되어 있는 데이터 요소들을 얼마나 많이
사용하고 있는가의 측정으로 주로 화면정의서를 통해 계산된다. (How)

  ① EI (External Input) - 외부입력
  ② EQ (External Query) - 외부조회 
  ③ EO (External Output) - 외부출력 (가공)
DET/FTR
미조정기능점수 데이터 기능수 + 트랜잭션 기능수
조정인자 결정 14개 기술적복잡도 요소에 영향도(0~5)를 평가하여 합산한다.
 - 총영향도 = 항목(14개) x 영향도(0~5)
 - 기술적복잡도(TCF) =  0.65 + (총영향도 x 0.01) 
조정기능점수 결정 FP(기능점수) = FC(Function Count) + TCF(기술복잡도)
조정기능점수 = 미조정기능점수 x 기술적복잡도(TCF)
                   = (데이터기능수+트랜잭션기능수) x (0.65+복잡도x0.01)


14개 기술 복잡도 항목

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


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

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


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

용어 설명
 1.사용자관점  사용자의 업무적 요구를 사용자의 용어를 사용하여 공식적으로 기술한 것
2. 사용자식별가능한
   (User Identifiable) 
 사용자와 소프트웨어 개발자 모두가 이해하고 합의한 프로세스와 데이터 그룹에 대해 정의된 요구사항을 지칭한다
3.  측정범위 
  (Counting Scope) 
측정대상 소프트웨어의 집합으로 측정목적으로 결정된다
 4. 내부논리파일 (ILF)  주요의도는 측정대상 어플리케이션의 하나 또는 그 이상의 단위 프로세스를 통하여 유지되는 논리적으로 연관된 데이터그룹또는 제어정보를 보관하는데 있다
 5. 외부연계파일 (EIF) 주요의도는 측정대상 어플리케이션 경계 내의  하나 또는 그 이상의 단위프로세스를 통하여  참조된 데이터를 보관하는데 있다.    
    ▶특정 어플리케이션에서 외부연계파일로 측정된 것은 반드시 다른
      어플리케이션의 내부논리파일로 존재하여야 한다.
    그러나 측정대상 어플리케이션 내에서는 유지되지 않는다.
  6. 외부입력 ( EI )  - 단위프로세스의 주요의도는 하나 이상의 내부논리파일을 유지하거나 
  시스템 동작을 변경하는것이다. 
- 데이터 또는 제어정보를 어플리케이션 경계 밖에서 받아들인다.
- 어플리케이션 경계를 통해서 들어온 데이터가 시스템의 동작을 바꾸는 제어
  정보가 아니라면, 적어도 하나의 내부논리파일을 유지해야 한다.
  7. 외부출력 (EO)  - 데이터나 제어정보를 어플리케이션 경계 밖으로 보낸다. 
 - 단순조회 이상의 처리로직을 통해 사용자에게 정보를 제공하는 것이다.
     ① 적어도 하나이상의 수학공식 또는 계산을 포함한다.
     ② 파생 데이터를 만들어 낸다.
     ③ 적어도 하나 이상의 내부논리파일(ILF)을 유지한다.
     ④ 어플리케이션의 동작을 변경한다.
  8. 외부조회 (EQ)  - 데이터나 제어정보를 어플리케이션 경계 밖으로 보낸다. 
- 주요의도는 내부논리파일,외부연계파일로부터 데이터 또는 제어정보를 사용
  자에게 정보를 제공하는 것이다. (가공없이 그냥 그대로 제공하는 것을 말함)
  ① 내부논리파일 또외부연계파일로부터 데이터 또는 제어정보를 조회한다.
  ② 수학공식 또는 계산을 포함하지 않는다.
  ③ 파생 데이터를 만들지 않는다..
  ④ 시스템 동작을 변경하지 않는다.
  ⑤ 내부논리파일(ILF)을 유지하지 않는다.
9. 코드데이터
  (Code Data)
 - 코드데이터는 때로 리스트데이터 또는 중계데이터라 불러지며 사용자가 
   항상 직접적으로  명시하지 않는다. 개발자가 사용자의 기술적 요구사항들
   을 맞추는 중 코드 데이터는 생기게 된다.
 - 코드데이터는 어떤 속성이 가질 수 있는 유효한 값들의 범위를 표시한다.
 - 일반적으로 코드 데이터의 속성들은 코드,묘사,그리고/또는 코드로 표현하는
   다른 표준속성들이다.
       Ex) 표준약자, 유효날짜, 종료날짜. 역추적감리데이터 등등
10. 비지니스 데이
    (Business Data)
- 핵심사용자 데이터 또는 비지니스 객체라 일컬어질 수 있다.
- 확인되는 모든 엔티티 중 상당한 비율을 차지한다.
11. 참조데이터
    (Reference Data)
- 비지니스데이터 유지보수를 가능하게 하는 비즈니스 규정들을 위해 저장
  되는 데이터 형태
      Ex) 급여어플리케이션에서 소득 별 정부 세금비율과 유효날짜를 가지고
           있는 데이터
 - 확인되는 모든 엔티티 중 참조데이타가 차지하는 비율은 적다.
12. 공유데이터
    (Shared Data)  
- 다른 시스템과 데이터를 공유하는 데이터는 다음의 방법으로 전송된다.
- 온라인화면을 통해서 
- 타시스템이 직접 데이터 파일에 접근하여
- 전송파일 통해서 
- 직접 온라인 실시간 정보 요청을 통해서 
- 웹어플리케이션을 통해서



728x90
반응형
LIST

+ Recent posts