[소공 목차]

 

I. 품질속성 반영여부 평가, SW Architecture 평가의 개요

. SW 아키텍쳐 평가 정의

- SW 완전성 향상 위해 SW 계획수립 단계에서 SW 아키텍쳐 적합성을 측정하는 평가

. SW 아키텍쳐 평가 수행 시 기대효과

- (안전성 확보) 사전 위험 요소 식별 통한 SW Failure 위험 제거

- (신뢰성 확보) 객관적인 평가 통한 이해관계자들의 신뢰성 확보

- (실패 비용 감소) SW 실패 위협 조기 발견에 따른 실패 비용 감소(1:10:100 법칙)

 

2. SW Architecture 평가 방법론

평가 유형   내 용
예측 평가 Scenario Based -기 정의된 Profile에 의존하여 평가(ATAM, CBAM, SAAM)
-시나리오 정밀도에 좌우
실무 평가 Simulation Based -BMT(BenchMarking Test) 시뮬레이션 기반 평가
사례 평가 Experience Based -정량적인 분석이 어려운 경우 적용하는 경험 기반의 평가
-
정량적 평가 Mathematical
Model Based
- 기준 모델을 수치화하고 이를 기초로 평가하는 수학적 기반 모델
- 정적 평가

- 각 평가 방법은 복합적으로 사용 가능

 

3. SW 아키텍처의 평가모델 구성도 및 평가 기법

. SW 아키텍처의 평가 모델 구성도

일반적으로 정방향 분석인 ATAM, CBAM 많이 사용

 

. SW 아키텍처 평가 기법

평가유형 상 세  설 명
SAAM Software Architecture Analysis Method
최초로 정리된 평가방법다양한 수정 가능성들의 관점에서 아키텍처 분석
수정 가능성과 기능분석 중심의 최초의 아키텍처 평가방법
ATAM Architecture Trade-off Analysis Method
아키텍처가 품질속성을 만족시키는지 판단품질 속성간 상호작용 확인 단계
아키텍처가 목표로 하는 품질만족도각 품질간의 연관성품질 목표간의
 Trade-off가 있는지 파악 가능한 아키텍처 평가방법
CBAM Cost Benefit Analysis Method
- SAAM, ATAM의 기술적 아키텍처 및 경제성 평가까지 하여 수익이 최대가 될 수 있도록 의사결정을 도와주는 SW아키텍처 평가모델
ARID Active Reviews for Intermediate Designs
부분 아키텍처를 아키텍처 초기에 평가하는 방법으로 시나리오 중심의 ATAM, SAAM과 설계검토 방법인 ADR(Active Design Review)를 혼합한 아키텍처 평가방법
특정부분 품질요소 집중
아키텍처 설계 초기에 검토하여 발생 가능한 위험 감소
ADR ·Active Design Review
·아키텍처 구성요소간 응집도 평가

 

[소공 목차]

1. 프로젝트의 성공을 위한 전담 조직, PMO의 개요

 가. PMO(Project Management Office)정의

  - 성공적인 프로젝트 수행을 위해 프로젝트의 자원, 인력, 일정 등을 체계적으로 관리하기 위해 조직된 프로젝트 전담관리 조직

  - '전자정부법 제64조의 전자정부사업관리의 위탁' 법령에 따라 전자정부사업을 효율적으로 수행하기 위해 전자정부사업을 전문지식과 기술능력을 갖추자에게 위탁하는 제도 (공공 PMO)

 나. PMO의 특징

특징 내 용
체계적인 관리  프로젝트 대형화, 복잡도 증가 시 체계적인 관리로 인한 원활한 프로젝트 수행 가능
위험최소화 및 품질향상 프로젝트 자원 효율적 배분 및 관리 통한 리스크 축소 표준화 및 통제 통한 품질 향상
중재 기능 다양한 이해관계자 간 원활한 의사 소통 통해 의견 조율, 이슈 중재 기능

2. PMO 주요 모델 및 유형별 특징

 가. PMO 주요 모델

 나.  PMO R&R 에 따른 유형별 비교   

구분 Weather Station Coach Control Tower
구성  소수 전문 인력 프로젝트 전문 인력 조직 차원
권한 약함 중간 강함
역할 조언자 조언자/관리자 관리자/책임
특징 Support Support + Control Control
방법론 프로젝트 관리방법론 개발 및 전파 공통 방법론 및 도구 사용 전파 모든 프로젝트 동일 방법론 적용
주요활동 진행상황 점검
Technical Support
프로젝트간 의사 소통
성과 기록/모니터링
프로젝트 계획, 진행, 의사 결정,자원 조정

 다. PMO 운영을 위한 성숙도 5단계 모델

  3. PMO 도입 프레임워크 및 구성요소

   가. PMO 도입 프레임워크

  나 PMO 구성요소

구분 구성원 역할
관리적 측면 전문 PM 전체 프로젝트 진행 및 관리
재무 관리자 프로젝트 단계별 재무현황 관리
일정 관리자 프로젝트 일정 모니터링 및 통제
고객인수 담당자 최종 제품의 고객인수 담당자
형상 관리자 형상관리 총괄 책임자
기술적 측면 품질 관리자 전체 프로젝트의 전체 품질 관리
개발기술 담당자 전문 Skill 및 아키텍처 담당자
형상관리 위원회 Configuration Control Board

 4. PMO 업무 범위와 역할

 가. PMO 업무 범위

     - 품질관리, 리스크관리 등 8개 주요 기능을 사람, 일, 시스템 관점으로 수행

나. 사업 단계 별 PMO의 역할

5. 도입된 PMO 제도의 한계점 및 보완 방안

현행 문제점 보완 대첵
예산 없이 제도 시행 - 단계적으로  의무화 방안 등 추진하여 본 사업에서 일부를 떼어 내 PMO 사업으로 사용 방지
예산 편성 기준 부재 - 현실적 PMO 예산 편성 기준이 포함된 예산편성 지침
명확한 도입대상 기준 부재 - PMO 도입 대상 사업의 세부적인 기준을 마련 발주기관 입장에서의 혼란 방지
PMO 도입 부정 인식 - PMO 품질 향상 사례 발굴
- PMO 제도 통한 프로젝트 관리 방안 가이드 제작 배포
PMO 권한과 책임 미흡 - 정보화 인력 순환배치 대상 제외
- EPMO제도 도입
감리업체와 PMO 업체와 이행관계 충돌 - PMO 제도 통한 전자정부사업의 품질확보 방안 가이드 제작 배포
- 개발단계별 품질확보 기법 및 기준 마련

-끝-

[소공 목차]

 

프로젝트 범위 관리(Project Scope Management)

 

1. 단계별 작업활동의 관리, 프로젝트 범위관리의 개요

1) 프로젝트 범위관리 정의

- 프로젝트 이해관계자의 요구사항을 분석하여 프로젝트 범위를 결정하고, 각 단계별 작업활동을 구체화하는 프로세스
- 프로젝트를 성공적으로 수행하기 위해 프로젝트에 필요한 모든 작업을 명시하여 포함하고 관리하는 프로세스 관리 과정

- (특징) 절차 정의 및 범위 확정, WBS, 관리영역 영향
  • 인도물 관점 또는 프로젝트 작업 관점에서 프로젝트가 산출해야 할 요소들을 통칭하며 제품 범위와 프로젝트 범위로 구분

2) 프로젝트 범위관리의 필요성

  • 프로젝트를 성공적으로 완수하기 위해 반드시 필요한 활동이나 산출물을 누락이나 중복 없이 관리
  • 통제되지 않은 범위 정의와 범위 변경으로 인한 프로젝트 생산성과 효율성 저하를 방지
  • 프로젝트 완수에 반드시 필요하지 않은 제품, 서비스, 산출물 등을 생성하는 골드 플레이팅을 방지
  • 프로젝트 일정, 원가, 품질, 위험, 조달 관리의 근간을 이루는 범위 관리는 프로젝트에 필수 요소

 

2. 프로젝트 범위관리 프로세스 및 활동

1) 프로젝트 범위관리 프로세스

  • 프로젝트 관리 계획 실현가능성과 구체성은 범위에 따라 결정

2) 프로젝트 범위관리 단계별 활동

단계 활동 산출물
① 범위관리 계획 수립 - 프로젝트 범위의 정의 및 검증, 통제하는 방법에 대한 계획을 수립하고 범위관리계획서를 작성하는 프로세스 범위관리 계획서
요구사항관리 계획서
② 요구사항 수집 - 이해관계자들이 필요로 하는 요구사항을 파악하고 문서화하는 프로세스 요구사항 문서
요구사항추적매트릭스
③ 범위 정의 - 프로젝트와 제품에 대한 내역 및 요건 등 상세 범위 기술서를 개발하여 프로젝트 범위를 정의하는 프로세스 범위기술서
④ WBS 작성 - 프로젝트 인도물과 업무를 작고 관리 가능한 컴포넌트로 세분화하는 프로세스
- 작업 분류 체계를 작성하기 위한 활동
WBS
⑤ 범위 확인 - 완료된 프로젝트 인도물의 인수를 공식화하는 프로세스 수용된 인도물
⑥ 범위 통제 - 프로젝트 상태와 제품 범위를 모니터링하고 범위 기준선의 변경을 관리하는 프로세스 작업 성과 정보
프로젝트 문서 갱신
  • 프로젝트 범위 관리 시 먼 미래는 예측하기 어려우므로 가까운 미래부터 세부적으로 관리하는 연동 계획 적용

 

3. 프로젝트 범위 통제의 위험요소

구분 Scope Creep (범위 끼어들기) Gold Plating (금 도금)
정의 통제되지 않는 변경 고갹의 요구를 넘는 과도한 품질향상 작업
현상 범위의 과도한 증가 일정 지연 및 범위의 증가
예방 WBS는 PM을 통해서만 변경 수행 품질 관리와 인력관리 활동 강화
위험 변경 제어 시스템으로 관리 고객의 기대 수준이 Gold Plating에 맞춰짐

 

[소공 목차]

 

Function Point의 개념

- 사용자 관점에서 사용자가 요구하고 사용자에게 인도되는 기능을 정량적으로 산정하여 소프트웨어 규모를 측정하는 방법

- (등장배경) LOC한계 -> 라인수 추정의 어려움, 언어마다 라인수 크게 달라짐

 

Function Point 특징

특징 설명
사전측정 가능 실제 개발 이전에 업무량 측정 가능
활용성 개발뿐만 아니라 기획, 운영 등 전 수명주기에 걸쳐 측정 가능
일관성 조직, 구현기술, 방법론과 무관하게 측정 가능
사용자관점 사용자가 요구하는 기능의 관점에서 측정
높은 분석능력 필요 기능도출을 위한 높은 분석능력 필요

 

Function Point 산정방법

 

Function Point 구성

유형 기능 내용
데이터 기능

내부논리파일(ILF) - Internal Logic File
- 측정 대상 어플리케이션 내부에서 유지되며 사용자가 요구한 기능을 수행하기 위해 읽히거나 참조되는 데이터 그룹의 모음(내부DB)


외부연계파일(EIF) - 측정 시스템 참조 데이터 집합
- 측정 대상 어플리케이션 외부에서 유지되며, 사용자가 요구한 기능을 수행하기 위해 읽히거나 참조되는 데이터 그룹(외부DB)

트랜잭션 기능 외부입력(EI) - 외부 입력(External Input) (입력 트랜잭션, 입력 화면)
- 어플리케이션 외부로부터 데이터 또는 제어 정보를 받아 들여, 내부논리 파일의 유지(추가/수정/삭제 등), 어플리케이션의 상태에 변경을 요구하는 단위 프로세스 
외부 출력(EO) - 외부 출력(External Output) (출력 트랜잭션, 출력보고서)
- 어플리케이션 내부에서 데이터 또는 제어 정보를 경계 밖으로 내보낼 것을 요구하는 단위 프로세스 
외부 조회(EQ) - External inQuery. 데이터 가공 없는 입출력
- 어플리케이션 내부에서 데이터 또는 제어 정보를 경계 밖으로 내보낼 것을 요구하는 단위 프로세스 

 

 

Function Point 산정 절차

(유범이의데이트)

 

산정절차별 상세 내용

1) 측정 유형 결정

종류 내용
개발 프로젝트
(DFP)
  • 처음 설치된 어플리케이션을 통해 사용자에게 제공되는 기능을 측정하는 것으로 프로젝트 개발 동안 계산
  • 초기 어플리케이션 기능점수로 계산되는 기능과 데이터 컨버전을 위해 필요한 기능 포함
유지보수 프로젝트(EFP)
  • 새로운 기능의 추가, 기존 기능의 삭제, 기존 기능의 변경을 포함하여 기존 어플리케이션을 수정하여 사용자에게 제공되는 기능
어플리케이션(AFP)
  • 설치된 어플리케이션이 최종 사용자에게 제공하는 현재 기능
  • 기준 선 또는 설치된 기능점수에 해당
  • () 유지보수규모 산정

2) 측정 범위와 어플리케이션 경계 식별

구분 종류 내용
범위 및 경계 식별 범위결정 규모 계산 대상 소프트웨어의 하위 구성요소를 정의
기능점수 계산 목적에 따른 필요 기능을 식별
경계식별 내부어플리케이션과 외부 사용자 세계 간의 개념적 인터페이스
어플리케이션에 의해 유지되는 논리데이터를 둘러싸고 있음

3) 데이터 기능 계산

구분 종류 내용
데이터 기능
유형 식별
내부 논리 파일(ILF) 측정 대상 어플리케이션 내부에서 유지되며 사용자가 요구한 기능을 수행하기 위해 읽히거나 참조되는 데이터 그룹의 모음(내부DB)
외부 연계 파일(EIF) 측정 대상 어플리케이션 외부에서 유지되며, 사용자가 요구한 기능을 수행하기 위해 잃히거나 참조되는 데이터 그룹(외부DB)
복잡도 및 기여도 결정 레코드요소유형(RET) ILF또는 EIF 내부에 존재하는 것으로 하나의 정보를 구성하는 DB의 테이블과 같은 관련 데이터 그룹
사용자가 식별 가능한 데이터 요소의 서브 그룹
데이터요소유형(DET) RET에 존재하는 것으로 RET를 구성하는 개별 데이터 필드
  • RETDET 값이 결정되고 나면 복잡도와 기여도Metric이 정의된 테이블을 참고하여ILFEIF의 값이 산정

데이터 기능 복잡도Metric

  DET
1~19 20~50 >51
RET 1 Low Low Average
2~5 Low Average High
>5 Average High High

 

데이터 기능 기여도Metic

  복잡도
Low Average High
ILF 7 10 15
EIF 5 7 10
  • RET개수와DET 개수를 활용하여 복잡도를 먼저 구하고 기여도 테이블에 따라 기여도를 산출함

4) 트랜잭션 기능 계산

구분 분류 설명
트랜잭션
기능유형 식별
외부입력(EI)
  • 애플리케이션 경계 안으로 들어오는 데이터나 제어정보를 처리하는 단위 프로세스
외부출력(EO)
  • 애플리케이션 경계 밖으로 조회되는 파생 데이터 생성 같은 처리로직 포함 단위 프로세스
  • 데이터나 제어정보를 어플리케이션 경계 외부의 사용자 또는 다른 어플리케이션으로 내보내어 사용자의 요구를 처리하는 기능
) 가입한 회원의 평균 나이를 계산하는 과정과 같은 처리 로직이 있으며 파생 데이터가 발생
외부조회(EQ)
  • EO와 같으나 파생 데이터 생성과 같은 처리 로직을 포함하지 않는 단위 프로세스(계산 처리 없이 단순 데이터가 외부로 나가는 것)
복잡도 및 기여도 결정 참조 파일유형(FTR)
  • 트랜잭션 기능에 의해 조회/유지되는 ILF 또는 EIF(어플리케이션에서 참조하는 ILF EIF의 수)
데이터 요소유형(DET)
  • 사용자가 식별 가능하고 반복되지 않는 유일한 필드

 

EI기능 복잡도Metric

  DET
1~4 5~15 > 16
FTR <2 Low Low Average
2 Low Average High
>2 Average High High

 

EI기여도Metic

  복잡도
Low Average High
EI 3 4 6

 

EO, EQ 복잡도Metic

  DET
1~5 6~19 > 20
FTR <2 Low Low Average
2 ~ 3 Low Average High
> 3 Average High High

 

EO, EQ 기여도Metic

  복잡도
Low Average High
EO 4 5 7
EQ 3 4 6

 

 

5) 미조정 기능 점수(UFP, Unadjusted Function Point) 결정

 

6) 조정인자 결정(VAF, Value Adjustment Factor)

  • 측정되어지는 어플리케이션의 일반적 기능에 등급을 부여한14개의 일반 시스템 특성(GSC) 기반을 두고 각 특성은 영향도 정도의 파악할 수 있도록 적용 명세를 가짐
  • 영향도의 범위는 없음(0)에서 강함(5) 까지6등급으로 표시되고 조정 기능 점수는 미조정 기능점수의 ±35 %까지 조정이 가능

7) 조정 기능 점수 결정

  • 최종 조정된 기능 점수인 보정 후 개발 원가는 다음과 같은 공식으로 계산

 

기능점수 방식에 의한 소프트웨어 개발비 산정절차

 

 

간이법 vs. 정규법

구분 간이법 정규법
개념 기능 점수 산정 시 기능 유형별 평균 복잡도를 적용하여 기능 점수를 산출하는 방법 기능을 도출하고, 각 기능의 유형별 복잡도 고려하여 정확한 기능점수 산정을 필요로 할 경우 사용되는 일반적 방법
목적 개략적인 기능점수 측정 상세 기능점수 측정
적용시기 예산 수립/제안단계 분석/설계 단계 이후
측정항목 - 데이터 기능
- 트랜잭션 기능
- 데이터 : DET/RET
- 트랜잭션 : DET/FTR
복잡도 - 평균 복잡도 - 기능별 복잡도
장/단점 - SW 규모 측정 신속성, 산출 비용 최소화
- 제한적 데이터 활용
- 정확한 SW 규모 측정 재활용 가능
- 사업초기 적용 어려움
관련기준 - IFPUG 기능점수 측정 매뉴얼(CPM) - SW 사업대가 기준의 평균 복잡도를 반영

 

[소공 목차]

 

개념 : 비즈니스 연속성 보장 기법

  • 시스템에 의해 제공하는 비즈니스의 연속성과 안정성을 보장하기 위해 운영 환경에 소스 배포 시 서비스가 중단되지 않도록 코드를 배포 할 수 있는 기술
  • 소프트웨어 배포 : 소프트웨어 개발 이후 결과물을 고객에게 제공하는 방법, 시스템을 중단하는 중단배포와 시스템의 중단없이 배포하는 무중단 배포로 부류

중단배포의 문제점

문제점 설명
다운타임 발생  - 24시간 항상 가동되어야하는 서비스의 경우 문제 발생 가능
무결성 저하  - 다중 서버 이용시 서버간 시차로 인한 데이터 중복 발생 가능
롤백시 중단  - 배포시 문제 발생할 경우, 롤백시에도 다운타임 발생

무중단 배포 기법의 종류  

(1) Rolling Update(롤링 배포)

구분 설명
개념 - 일반적인 배포를 의미하며, 단순하게 인스턴스(또는 서버)에 대해 동일한 인스턴스를 띄우고, 준비가 되어 있는 상황에서 1개씩 Rolling을 통해 점진적으로 인스턴스를 변경하는 기법
- Ramped, Incremental 이라고도 불리며, 기존에 사용하고 있었던 기본적인 배포 전략 방식
장점 - 관리 및 롤백이 용이
단점 - 서버 처리 용량에 대한 서전 고려 필요 

(2) Blue/Green Deployment(블루-그린 배포)

구분 설명
개념 - Old 버전을 블루, New 버전을 그린으로 호명하고, New 버전을 모두 배포 후 서비스 준비가 되었을 때 모든 트래픽을 New 버전으로 한번에 Switching 을 하는 기법 
- Red-Black 이라고도 불리며, 서버가 2개가 다 active이기 때문에 Rollbak이 다소 쉽게 처리 가능
장점 운영 환경에 영향을 주지 않고, 실제 서비스 환경으로 신버전 테스트가 가능
단점 시스템 자원이 두배로 필요하여 비용이 증가

(3) Canary Release(카나리 배포)

구분 설명
개념  - 트래픽 제어를 통해 일부 사용자만 신규 서버로 접속하게 하여 모니터링과 디버깅을 수행 한 후 문제가 없는 경우 모든 서버로 교체하는 기법 
 - 수정한 코드가 워낙 많이 바뀌어서 불안할 경우 점진적으로 배포하는 형태를 통해 위험 감소 가능
장점  - Risk 를 빠르게 감지 가능, A/B 테스트로도 활용 가능
단점  - 네트워크 트래픽에 대한 제어 부담

+ Recent posts