소프트웨어

소프트웨어의 정의
프로그램과 프로그램의 개발, 운용, 보수에 필요한 관련 정보
소프트웨어 특성 및 특징 가. 소프트웨어 특성
비가시성(invisibility) : 건축이나 자동차는 그 생산물을 보고 그 구조를 쉽게 파악할 수가 있으나 소프트웨어는 그 생산물의 구조가 코드 안에 숨어 있음
복잡성(complexity) : 개발 과정이 복잡할 뿐만 아니라 전산화 대상 업무, 소프트웨어 시스템 자체가 난해 함 나. 소프트웨어 특징
복제 : 적은 비용으로 복제 가능
테스트 및 수정 : 언제나 테스트 및 수정이 가능
마모 : 소프트웨어는 마모에 의하여 소멸되지 않음
규칙 : 요구나 환경의 변화에 따라 적절히 변형
소프트웨어의 유형 가. 소프트웨어 기능에 따른 유형

유형 특징 응용 소프트웨어 비즈니 업무 등 한 회사 또는 기관의 내부에서 사용하는 시스템 급여 시스템, 회계 시스템, 재고관리 시스템, 수강신청 등 학사업무 시스템, 은행 시스템 시스템 소프트웨어 운영체제, 장치 드라이버, 컴파일러, 코드라이브러리 네트워크 시스템, 데이터베이스 시스템

나. 소프트웨어 개발에 따른 유형

유형 특징 주문형 소프트웨어 (custom software) 특정 고객 또는 기업의 요구를 만족시키기 위하여 제작한 소프트웨어 패키지 소프트웨어 (package software) 패키지화하여 상업적으로 판매하는 소프트웨어 워드프로세서, 스프레드시트, 한글 소프트웨어 프로토타입 소프트웨어 실현 가능성을 타진하고 사용자의 요구를 상세히 파악하기 위하여 표본으로 만들어진 소프트웨어 임베디드 소프트웨어 다른 시스템에 내장된 소프트웨어

소프트웨어 시스템 특성

특성 설명 서브시스템 시스템은 관련 깊은 서브시스템들로 구성 교통시스템은 신호기, 신호체계, 도로망 등 여러가지 요소가 밀접하게 연관 기능적 분할 시스템은 규모가 작은 부속 시스템(서브시스템)들로 나눔 시스템 경계 시스템은 어떤 것이건 시스템과 주변 환경을 구분할 수 있는 경계 존재 입력과 출력이 만나는 곳 자동화 경계 시스템이 자동화된 부분과 수동 작업 부분을 나누는 경계

소프트웨어 공학

기업 경영전략 달성을 위한 소프트웨어 공학의 목표 가. 소프트웨어 공학의 정의
소프트웨어의 개발과 운영, 유지보수, 소멸에 대한 체계적인 접근 방법
체계적인 접근 방법 : 소프트웨어 개발에 사용되는 방법이 일회성이 아니라 반복 사용이 가능
사용자가 요구하는 소프트웨어 요구사항을 공학적인 기법을 이용하여 개발하고 관리/운영하기위한 이론 및 실무적 기술
소프트웨어 위기를 극복하기 위한 공학적/실무적 차원의 접근 학문 나. 소프트웨어 공학의 목표

목표 설명 경영적 목표 기업 경영전략 달성 IT Governance 체제 수립 재무적 이익 달성 관리적 목표 IT투자비용의 감소, 사용자 만족도의 향상 업무 효과성, 효율성의 향상 프로세스 낭비 요소 제거 기술적 목표 소프트웨어 자산의 재사용, 고품질의 소프트웨어 생산, 소프트웨어 개발 생산성 향상 일정/비용/인력의 최대 활용을 통한 납기 유지

기업 경영 전략 달성을 위한 소프트웨어 공학의 원리 가. 소프트웨어 공학의 구성요소

구성요소 설명 원리 정형성과 엄격, 관심사의 분리, 모듈화, 추상화(기능, 자료, 제어), 변화 예측, 일반화, 점진화 기법 인터뷰, 자동화, 방법론, 프로세스 성숙도, 프레임워크 언어 4GL, Embedded, UML 도구 CASE Tool(자동화 도구) 프로세스 자동화 도구, 모델링 도구 산출물 요구사항 명세서, 분석/설계 기술서, 테스트 계획/결과서, 프로젝트 관리 계획서

CASE(Computer Aided Software Engineering) 도구 : 소프트웨어 시스템을 분석하고 설계할 때 사용하는 도구
CASE 도구 기능

CASE 도구의 기능 설명 UML 모델링을 지원 - 소프트웨어 시스템의 분석 단계와 설계 단계의 산출물을 작성(유즈케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램 등을 작성) - UML 다이어그램의 오류를 검증(시퀀스 다이어그램에서 사용된 객체가 클래스 다이어그램에 존재하는지를 바로 체크) 순공학 기능과 역공학 기능을 지원 - 순공학 : 모델링의 결과를 이용하여 소스 코드를 생성 - 역공학 : 소스 코드를 이용하여 모델링을 작성 모델링 결과를 문서로 생성하는 기능을 지원 모델링의 결과를 활용하여 문서를 자동 생성

나. 소프트웨어 공학의 원리

원리 설명 사례 정형성과 엄격 구현하려는 소프트웨어에 대한 정형화된 명세 및 엄격한 설계 UML 관심사의 분리 복잡한 소프트웨어 구조에 대한 문제의 분리를 통한 단순화 AOP 모듈화 유사한 기능의 모듈 구성을 통한 그룹핑 응집도, 결합도 추상화 일반 사물에 대한 추상적인 모형의 설계 설계 패턴 변화 예측 소프트웨어 공학의 기술 트렌드를 미리 예측 SOA, Web3.0 일반화 구체적인 사실로부터 일반적인 이론을 추출 CBD 점진화 개략적인 단계부터 구체적인 단계로 점진적인 진화 단위->통합->시스템 테스트

소프트웨어 공학에서 발생하는 문제점 가. 소프트웨어 위기(software crisis)
소프트웨어 비용이 하드웨어 비용을 초과하는 현상 나. 지연과 낮은 신뢰도
지연 : 일정이 조금 지연되거나 예산이 초과된 것이 아니라 관리할 수 없을 정도가 되어버린 프로젝트
낮은 신뢰도 : 예상대로 작동되지 않거나 예상하지 않았던 오작동을 일으키는 현상 다. 유지보수와 재작업
유지보수 비용이 소프트웨어 개발비용을 초과
오류 : 잔존하는 시스템 오류 때문에 유지보수를 진행
소프트웨어 공학을 지원하는 기술의 유형 및 유형별 특징 가. 소프트웨어 공학 기술의 유형

유형 설명 사례 개발기술 요구공학 기술, SW설계 기술, SW구현 기술, SW테스팅 기술, SW유지보수 기술 Object Z, UML, ERD, Spring, Refactoring 개발 지원기술 SW재사용 기술, SW프로세스 기술, SW정보저장 기술 CBD, SOA, CMMi, DBMS, ITIL 관리기술 프로젝트 관리기술, SW품질관리 기술, 형상관리 기술, 교육 및 커뮤니케이션 기술, 문제해결 기술 ISO9126, ISO12119, Inspection, CVS, SVN, PMBOK

나. 소프트웨어 공학 기술의 유형별 특징

유형 특징 사용자 개발 기술 개발의 생산성, 구체적인 사용자 요구사항의 구현에 관여, 코딩과 연관 개발자, 모델러, 분석가 자동화와 정형화 및 표준화가 요구되는 기술 개발 지원기술 개발/운영의 생산성 향상에 기여 PMO, QA, DBA, EPG 자동화를 통한 개발자의 부담 감소에 기여 강제성이 부여되며 전사적인 관리가 필요 관리 기술 소프트웨어 품질과의 관계 PM, PMO, QA, 고객사 사용자, Steering Committer 관리자의 관점을 지원함 프로젝트 전체적인 관리를 가능하게 함

기업 경영전략 달성을 위한 소프트웨어 공학의 적용방안 가. 프로세스의 정립(CMMi, SPICE, ITIL) 나. 개발 방법론의 정립(구조적공학, 정보공학, 객체지향) 다. 인적 자원의 개발(PSP, TSP) 라. 효과성(ROI, TCO), 효율성, 안정성 관점으로 감리/감사의 필요성
소프트웨어 공학의 규모(scale) 및 품질과 생산성 가. 소프트웨어 공학의 규모
대규모 프로젝트는 엔지니어링과 프로젝트 관리 기법이 필요함
프로젝트 엔지니어링 : 방법, 절차, 도구
엔지니어링 원리 : 비용, 일정, 품질

나. 품질과 생산성 - 엔지니어링 원리와 같이 비용, 일정, 품질을 지향 - 소프트웨어 품질(ISO 9126)

속성 설명 기능성(functionality) 소프트웨어가 사용될 때 월래 정한 또는 내재된 요구를 만족 시키는 기능을 제공하는 능력 신뢰성(reliability) 소프트웨어가 정해진 수준의 성능을 유지할 수 있는 능력 사용용이성(usability) 쉽게 이해되고 배울 수 있고 사용될 수 있는 능력 효율성(efficiency) 사용되는 자원의 양에 따라 적절한 성능을 제공할 수 있는 능력 유지보수성(maintainability) 정정, 개선, 적응시킬 목적으로 수정될 수 있는 능력 이식성(portability) 별도의 작동이나 수단 없이 다양한 환경에서 적용될 수 있는 능력

=> 기능성 : 적합성, 정확성, 보안성 => 사용용이성 : 이해용이성, 학습용이성, 운용성 => 유지보수성 : 변경용이성, 시험용이성, 확장성 => 이식성 : 적응성, 설치용이성 7. 소프트웨어 공학의 프로세스 가. 요구분석 : 문제를 이해하고 명확히 정의 - 요구명세서(requirement specification) : 문제를 분석하고 그 핵심을 이해한 후에 요구를 문서로 정리 나. 설계 : 해결책을 결정하고 설계 - 아키텍처 설계 : 시스템을 여러 컴포넌트의 집합체로 보고 각 컴포넌트들이 요청한 결과를 위하여 어떻게 상호작용 하는지에 초점 - 상세 설계 : 모듈이 소프트웨어 안에서 어떻게 구현될 수 있는지에 집중 다. 코딩 : 설계된 해결책을 구현 라. 테스팅 : 프로그램 검증, “요구, 설계, 코딩 오류 검증” - 단위 테스팅(unit testing) : 모듈이나 컴포넌트를 개별적으로 시험 - 통합 테스팅(integration testing) : 모듈이 시스템으로 통합되면서 모듈 사이의 연결을 시험 - 시스템 테스팅 : 시스템이 모든 요구를 만족하고 있는지 명세서에 기술된 대로 실행되는지 시험 - 인수 테스팅(acceptance testing) : 고객의 실제 데이터를 가지고 시스템이 잘 실행되는지 고객에게 데모 8. 소프트웨어 메트릭 가. 프로덕트 메트릭 : 개발한 프로덕트 - 소프트웨어 자체의 특성을 계량화 나. 프로세스 메트릭 : 소프트웨어 개발에 사용된 프로세스의 생산성을 계량화 - 생산성, 비용, 자원요구, 품질보증의 효과 측정, 개발 기법과 도구의 효율과 같은 사항을 측정

SW 신뢰성 가. SW 신뢰성(SW Reliability)의 정의
규정된 환경하에서 주어진 기간 동안 요구된 기능을 수행하는 시스템 또는 컴포넌트의 수행 능력
특정 환경에서 일정 기간 동안 결함 없이 작동할 확률
SW가 소기의 작동 환경에서 다양한 부하에서도 정확하고 일관된 결과들을 반복적으로 만들어 낼 수 있는가에 대한 확신할 수 있는 정도
특정 시간 동안 특정 조건하에서 컴퓨터 프로그램의 임의의 연산이 실패할 확률 예) 프로그램 A가 처리시간 8시간 동안 100번 중 96번만 정확하게 작동할 때 프로그램 A의 신뢰도는 0.96이라고 함.
ISO/IEC 9126에서는 SW 신뢰성을 “SW품질특성”으로 나타내며, 성숙성(Maturity), 장애 허용성(Fault tolerance), 복구성(Recoverability), 표준적합성(Compliance)의 품질부특성을 가진 것으로 정의 나. HW와 SW 신뢰성 차이

구분 HW 신뢰성 SW 신뢰성 Lifecycle

특징 자체 특성으로 인하여 제품의 소모나 외부 요인에 의한 고장으로 인해 그 신뢰성이 저하 코드 내 각 인자 값의 잘못된 설정 또는 Logic이나 알고리즘의 잘못된 구현 영향 비교적 외부 환경으로부터 민감한 영향을 받으며 시간이 지나면 고장률이 급증함에 따라 신뢰도가 떨어짐 양산 또는 출시 후에 활발하게 사용되면서 문제점들이 들어나게 되어 결과적으로 고장률이 증가 개발자의 조치(Upgrade 또는 Patch)로 고장률이 낮추지는 단계들을 수차례 거치는데 이러한 안정화 단계를 거치게 되면 시간의 흐름과는 상관없이 일정한 고장률을 가짐

SW 신뢰성 연구 가. SW 신뢰성 Trade-off
신뢰성 목표가 너무 높게 설정되면 인도 시점이 미뤄지고, 개발 비용이 증가
신뢰성 목표가 너무 낮게 설정되면 사용자는 큰 불만을 가지고, 산업의 특성에 따라서 심각한 인명상의 피해 또는 재산상의 손해까지도 발생 나. SW 신뢰성 예측 모델 및 추정 모델간의 차이

구분 예측 모델 추정 모델 참고수치 경험적인 수치를 사용 현재 SW 개발에 들이는 노력을 산출하여 사용 개발 프로세스 상에서 적용 시 SW 테스트 이전에 수행 또는 개념(Concept) 설정 초기 단계에서 적용 개발 프로세스 후반 부분에 적용 (초기 단계에서는 적용하지 않음) 기준시점 미래 시점에서의 신뢰성을 예측 현재 또는 미래 시점에서의 신뢰성을 추정

다. 소프트웨어 신뢰성의 추정 측정 - 신뢰도의 측정은 실패(Failure)가 발생하는데 걸리는 평균시간으로 측정한다. 즉, MTBF(Mean Time Between Failure) 이다. - MTBF = MTTF + MTTR - MTBF(Mean Time Between Failure) : 고장 후 다음 고장까지 걸리는 시간 - MTTF(Mean Time To Failure) : 복구 후 실패하는데 까지 걸리는 시간 <평균 가동 지속시간> - MTTR(Mean Time To Repair) : 고장 후 복구하는데 까지 걸리는 시간 <평균 고장 지속시간> 3. SW 신뢰성 향상 방안 가. 소프트웨어의 오류를 줄이는 것으로, 소프트웨어의 Verification & Validation, 시험 등의 공학적 기법을 통해 소프트웨어의 오류를 검출하고 제거 나. Coding Rule 제정을 통한 관리 - 실수와 모호함들을 해결하기 위해 SW 코딩 룰을 제정하여 코딩 초기 단계에서부터 잠재적 결함들을 예방 다. 잠재적 오류 검출 활동 - 다수의 개발자가 협업을 통해 개발하는 프로젝트의 경우 각 개발자들의 산출물들을 통합하는 과정에서 많은 오류들이 발생 - 코딩 규칙을 제정하여 적용함과 동시에 정적분석 활동을 수행하도록 하여 잠재적인 결함을 최대한 검출 라. SW 단위 테스트(Unit Testing) 수행 - 실제의 타겟 환경에서 정확하게 수행을 하는지 설계 단계에서 도출된 테스트 케이스를 기반으로 확인하는 테스팅 - 하나의 소프트웨어 모듈이 정상적으로 기능을 수행하는지 여부를 시험하는 최소 수준의 테스트 - 화이트 박스 테스트(White Box Test) 마. Code Coverage 확보

분야별 SW 신뢰성 향상 방안

구분 설명 IEC 61508(기능안전규격 SW분야) 단위 테스트, 동적 테스트, 정적 테스트 신뢰성의 기준을 단일간의 계약에 의해 결정 ISO 26262(자동차 SW분야) 단위 테스트, 동적 테스트, 정적 테스트 신뢰성의 기준을 양자간의 계약에 의해 결정 IEC 62279(철도 SW분야) 단위 테스트, 동적 테스트, 정적 테스트 신뢰성의 기준을 양자간의 계약에 의해 결정

가용성(Availability) 가. 가용성의 정의
프로그램이 주어진 시점에서 요구사항에 따라 운영되는 확률 나. 가용성의 측정
가용성은 소프트웨어 유지보수성의 간접적인 측정
신뢰성은 MTTF, MTTR에 똑같이 민감하나 가용성은 MTTR에 좀 더 예민함
가용성(1)=MTBF/(MTBF+MTTR)
가용성(2)=MTTF/(MTTF+MTTR)
가용성(3)=MTTF/MTBF
안전성 (Safety)
안전성은 소프트웨어에 부정적으로 영향을 주고 전체 시스템이 실패하는 원인이 되는 잠재적인 위험의 식별과 평가에 초점을 맞추고 있는 품질보증 활동임
안전성을 위한 활동 : 모델링, 분석과정
안전성 분석 기법 : 결함 트리 분석(Fault Tree Analysis), 실시간 논리(RTL : Real Time Login), Petri-Net

프로세스

개발 프로세스 : 프로젝트에서 이루어져야 할 중심 프로세스
수행해야 할 개발과 품질보증 작업
code and fix 형
폭포수 모델(waterfall model)
프로토타입 모델(prototype model) : 사용자의 의견(feedback)이 중요한 모델
점증적 개발 모델(incremental model) : 반복적 모델, 점증적 모젤, 나선형 모델
나선형 모델(spiral model) : 위험관리를 중요시하는 모델
V모델 : 테스트와 검증을 강조하는 모델
일정중심 설계 모델(design to schedule model) : 출시 일정을 정확히 맞추기 위한 모델
애자일 개발 프로세스
프로젝트 관리 프로세스 : 계획, 모니터링과 제어, 분석
비용, 품질, 기타 목표를 맞추기 위한 계획, 제어 작업
프로젝트를 수행하여 프로젝트의 목적을 달성에 초점
기간 : 프로젝트가 수행하는 동안
개발 프로세스와 프로젝트 관리 프로세스 관계
소프트웨어 형상관리 프로세스 : 변경을 관리하여 제품의 일관성을 유지 가. 정의
개발 중에 발생하는 변경을 자체적으로 컨트롤
시스템을 구성하는 아이템을 식별하고 정의하며 이들의 변경을 생명주기 동안 관리하고 아이템의 현재 상황과 변경 요청을 기록, 보고하며 아이템의 완벽성과 정확성을 검증하는 작업 나. 형상관리와 개발 프로세스 관계
제품 진화에 의한 변경
버그 수정에 의한 변경
요구 변경 다. 형상관리 기능
프로그램의 최신 버전 유지
지정된 버전으로 되돌아 갈 수 있는 기능
무허가 변경이나 삭제를 방지
현 시스템에 대한 모든 정보, 문서 등의 정보를 모아 보관 라. 형상관리 메커니즘
형상관리 대상 파악과 베이스라인 지정
버전 관리
접근제어
품질보증 프로세스 : 소프트웨어 프로젝트의 프로세스와 프로덕트에 대한 품질을 관리하고 향상시키는 것 가. 인스펙션 프로세스 : 개발 결과에서 결함을 찾거나 방지하기 위한 노력 나. 프로세스 관리 프로세스 : 소프트웨어 프로세스를 개선
프로세스를 개선하여 생성된 결과의 품질과 생산성을 향상에 초점
기간 : 프로젝트가 진행되는 기간을 초과한 긴 시간 동안

개발 프로세스

I. 소프트웨어 개발 생명주기, SDLC 개요 가. SDLC(Software Development Life Cycle) 정의 - 소프트웨어를 타당성 조사로부터 분석, 설계, 개발, 시험, 유지보수, 폐기까지의 전 과정을 하나의 주기로 보는, 소프트웨어 공학 패러다임. 나. SDLC의 특징 1) SW 규모가 커지고 SW 위기(많은 실패)에 대한 대처 해법으로 제기 2) SW의 품질(발주자 만족) 및 개발 생산성(개발자 만족) 확보가 목적 3) SW 개발 프로젝트의 전체 프로세스를 효과적으로 관리할 수 있는 모델을 제시(용어/산출물 표준화 및 진행상황 파악) II. SDLC의 구성도 및 구성요소 가. SDLC 구성도(프로세스)

소프트웨어의 정의, 개발, 지원(폐기)단계에 대한 생명주기 나. SDLC 구성요소(단계)

구분 내용 계획 - 사용자의 요구에 대한 타당성 조사 및 요구 명세화 - 예)요구사항 정의서 분석 - 대상이 되는 문제영역과 사용자가 원하는 Task 이해 - 예) 개념 모델 및 비즈니스 모델 설계 - 분석내용을 세분화하여 구현될 수 있는 형태로 전환 - 개발환경(개발언어, OS 등)에 종속적인 구현방안 설계 개발 - 실행 코드 생성(프로그래밍) 시험 - 발생 가능한 프로그램의 오류 탐색 및 수정 - 알파테스트(In-house), 베타테스트(by User) 등 유지보수 - 인수 완료 후 발생하는 모든 개발 활동 - Upgrades(““perfective””), Fixes(““corrective””)

다. SDLC 대표유형(모델)

모델 설명 폭포수 모델 (Waterfall) - 각 단계별 승인을 거쳐, 순차적-하향식으로 개발이 진행되는 고전적 생명주기 모델 - 장점 : 이해 쉬움, 단계별 검토/승인, 체계적 관리용이 - 단점 : 요구사항 도출 어려움, 상위단계 지연이 하위단계에 계속 누적 지연, 개발 중후반 문제점 발견시 대처 곤란 프로타이핑 모델 (Prototyping) - 핵심적인 기능을 샘플로 만들어 평가 후 본 개발을 진행하는 점진적 개발 방법 - 장점 : 요구사항 도출용이, 의사소통 향상 - 단점 : 사용자의 오해(완제품), 폐기시 비용 손해 나선형 모델 (Spiral) - 폭소수와 프로토타입 모델의 장점에 위험분석을 추가한 모델 - 장점 : 점진적 개발로 실패위험 감소, 테스트 용이 반복적 모델 (Iterative) - 시스템의 여러번 나누어 개발하여 완성하는 모델 - 증분(Incremental) : 시스템을 분할하여 병행/순차 개발 - 진화(Evolutional) : 프로토타입을 재사용/진화시켜 개발 RAD기법 모델 - 산출물을 최소화하고, 시스템을 2~3개월의 짧은 주기로 나누어 순차적으로 개발하는 모델 - 장점 : 신속한 개발, 적시성(Time-to-market) 충족 - 단점 : 기술적 위험 부담, 구성원의 실력/책임감 필요

I. SDLC 모델 선정 가. SDLC 모델 선정 기준 1) 프로젝트의 규모와 성격 2) 개발 방법 및 도구 3) 개발에 기간 및 비용 4) 개발과정에서의 통제수단 및 산출물 인도 방식 나. 프로젝트 특성 별 SDLC 적합 여부

특성 폭포수 프로토타이핑 나선 점진 반복 RAD 대규모

적합 적합 적합 적합

위험이 다수 존재

적합 적합 적합

Reference 부족 적합

적합 요구사항 불명확

적합 적합

장기간의 프로젝트

적합 적합

충분한 비용 확보

적합 적합

구현 난이도가 쉬움 적합

적합 정확성을 요구

적합 적합 적합

적극적인 고객 확보

적합

다. 프로젝트 별 적합한 SDLC 선정

프로젝트 타입 프로젝트 특성 SDLC 일반적인 구축 - 위험성이 적고, 기존에 진행된 유사 사례가 많은 경우 - 한정된 자원에 대한 제약 존재 폭포수 모델 대규모 재구축 - 프로젝트의 위험성이 높고, 연관되어 있는 도메인이 많은 경우 - CBD방법론을 활용해야 하는 경우 - 향후 변경의 여지가 많고, 요구사항 Fix가 어려운 경우 - 대규모의 프로젝트로 개발 도메인간 연관성이 적은 경우 점진적 모델 임베디드 시스템 - 소프트웨어 외에 여러 요소(HW, 사용자 인터페이스)를 고려하여야 할 경우 점증적 모델 프로젝트 타당성 검토 (Proof of Concept) - 프로젝트를 해야 하는지에 대한 여부 결정이 어려울 때 - 타당성 검증을 필요로 하는 경우 프로토타이핑 나선형모델 연구 형 개발 - 요구사항이 불명확 하고, 지속적인 검증이 필요 - 대규모의 비용이 확보 되어 있음 나선형 모델 소규모 - 단기간 내 요구사항 만족 폭포수 모델 - 단기간 내 요구사항 만족 - 자동화 도구 사용가능 - 고객의 참여를 통한 효율성 확보 RAD

II. SDLC 발전 방향 1) 객체지향 4세대 도구(4GL, 4th Generation Language)를 활용한 신속한 개발이 가장 보편적임 2) 신기술을 보유한 소수 전문가 집단을 통한 개발조직 형성 및 개발을 Lead하도록 함 3) 산업계의 요구로 RAD가 정착되어 가고 있음 4) 향후 CBD에 기반한 소프트웨어 모듈화 및 재사용 증대를 통해, 개발비용은 낮추고 생산성과 품질을 향상시키는 방향으로 발전 전망 ※ SDLC에서 나선형 모델과 애자일 방법론의 Scope

프로젝트 특성, 개발 방법/도구, 시간/비용, 통제 수단/산출물 인도 방식에 개발 방법론이 적용됨
나선형 SDLC 모델 : 전통적으로 사용되고 있는 폭포수 모델의 단점을 수용한 모델
Agile 개발 방법론 : 모델 개발의 Agility 추구하는 방법론

code and fix 형 가. 정의 : 공식적인 가이드라인이나 프로세스 없이 소프트웨어를 개발해 나가는 형태 나. 단점
중요한 작업(설계, 테스트)들이 무시됨
각 작업이 언제 시작되어야 할지 언제 끝날지 불명확
대규모 작업에 적용하기 어려움
개인의 작업을 리뷰하거나 평가하기 어려움
code and fix 형 개념도

하향식 접근 방법으로 추상화 모델링 하는 폭포수 모델 개념 가. 폭포수 모델(Waterfall Model)의 정의
계획, 요구사항분석, 설계, 구현(개발), 시험 및 유지보수 과정을 순차적으로 접근하는 방법
문서와 결과물에 중점
분석, 설계, 구현(개발), 시험 및 유지보수 과정을 순차적으로 접근하는 고전적 라이프사이클 패러다임(classic Life-Cycle Paradigm) 나. 폭포수 모델의 특징
표준화 되어 있는 양식과 문서 중심의 프로세스 및 프로젝트 관리 강조
Phase Testing : 각 단계별 검증->다음 단계 진행
결과물(Frozen Deliverable) : Phase Testing을 거친 산출물들은 정식변경 절차에 의해서만 변경 가능
단계별 작업순서에 의해 체계적 순차적으로 진행(하향식, 명확한 요구사항 정의 필요)
폭포수 모델의 프로세스 및 장∙단점 가. 폭포수 모델의 프로세스
각 단계는 산출물의 완벽성을 요구한다. 하지만 폭포수는 사용자가 소프트웨어를 볼 수 있는 시점이 완료된 이후이므로 사용자 요구사항 분석이 어려운 문제점을 가지고 있다. 그러므로 신규 사업과 같은 프로젝트 보다는 이미 경험이 있고 위험 낮은 프로젝트 모델로 적당하다.
사용자 의견이 다르거나 중간 결과를 점검한 결과 전 단계의 작업에 결함이 있다면 다시 수정하도록 전 단계로 돌아가는 피드백이 존재
응용분야가 단순하거나 잘 알고 있는 경우에 적합
비전문가가 사용할 시스템을 개발하는데 적합
폭포수 모델의 프로세스 및 주요 산출물, 적합한 프로젝트 특성 나. 폭포수 모델의 장∙단점

장점 단점 프로세스가 단순하여 초보자가 쉽게 적용 가능 처음 단계의 지나치게 강조하면 코딩, 테스트가 지연 중간 산출물이 명확, 관리하기 좋음 tool late working version 프로젝트 관리용이(진행과정 세분화) 사용자 피드백에 의한 반복단계 적용 불가능 기술 수준이 높고, 경험이 많은 경우 사용 초기에 고객 요구사항 정의가 어려움 일정예측 관리가 용이함 이전 단계 종결되어야 다음 단계를 수행 문서 등의 관리 및 적용이 용이 프로토타입과 재사용 기회가 줄어듦

폭포수 모형의 주요활동 및 산출물 가. 계획
문제정의
시스템의 성격을 파악하여 비용과 기간을 예측
개발 방법과 각 단계에 필요한 자원을 결정 나. 요구분석
기능, 성능, 사용 용이성, 이식성 등 목표 시스템의 품질을 파악
요구분석서(요구명세서) : 사용자와 개발자의 의사소통 수단으로 사용되므로 정확하고 간결하고 완벽하게 이해하기 쉽고 일관성을 유지하도록 작성 다. 설계
시스템 구조 설계 : 시스템을 이루는 모듈의 관계 구조
프로그램 설계 : 각 모듈 안에서의 처리 절차나 알고리즘을 설계
사용자 인터페이스 설계 : 사용자에게 보이는 부분을 설계
설계서(설계 명세서) : 소프트웨어 구조를 기술한 것으로 각 모듈의 기능과 모듈 사이의 관계 => 개략 설계서 : 모듈 관계를 고려하여 모듈의 구조를 기술 => 상세 설계서 : 모듈의 인터페이스를 정의 라. 구현
단위 테스팅(unit testing)
코드 검사(code inspection) : 코딩 스타일에 맞추어졌는지 눈으로 확인 마. 시험
통합 테스팅
시스템 테스팅
알파 테스트 : 내부에서 실제로 테스트
베타 테스트 : 선택된 사용자가 실제로 테스트 바. 인수
인수 테스팅(acceptance testing) : 설치 후 인수를 받는 사용자나 발주자가 시험
폭포수 모형(Waterfall, Classic, Phased Model)의 한계
설계와 코딩 및 테스트를 지연시킬 우려, 불필요한 문서작성 노력, 재사용의 기회 줄어듦
사용자의 요구에 대하여 정확한 의견 수렴 어려움, 프로그램 개발 상황의 반영 못함
폭포수 모델 적용 시 고려사항 1) 관리가 상대적으로 쉬우나, 요구사항의 변경에 대한 대응력이 떨어짐 2) 기술 위험이 낮고, 유사한 프로젝트 경험이 많은 경우 적용, 요구사항이 비교적 명확히 정의되어 있는 경우 적용

고객과 원활한 의사소통을 위한 프로토타이핑(Prototyping) 모델의 개요 가. 프로토타이핑 모델(Prototyping Model)의 개념
짧은 시간 내에 시제품을 개발하여 사용자가 요구사항을 미리 확인하고, 기술적 문제의 해결 가능성을 미리 확인할 수 있도록 한 소프트웨어 개발 모델(일회용, 진화용 시제품)
사용자 요구사항 도출을 위해, 시스템의 중요 일부분(시제품)을 우선 구현하여 시연 후, 요구사항을 다시 분석/반영하는 점진적 개발모델 나. 프로토타이핑 모델의 목적
요구사항을 명확하게 이해 및 완전하게 정의 : 사용자가 도출 요구사항의 문제점을 평가가능
설계 대안을 탐색 : 엔지니어가 사용자 인터페이스기법, 시스템의 사용편의성 최적화 등에 대 한 대안을 개발하여 평가
최종제품의 기능 및 성능을 향상 : 엔지니어가 최종제품이 갖추어야 하는 기능 및 성능 요구사항의 누락여부를 평가하여 그 결과를 타 구성품의 구축과정에서 반영 가능함 다. 프로타이핑 모델의 특징 1) 요구사항이 모호한 사용자와의 의사소통 도구로 활용 가능 2) 요구사항 도출이 어려운 폭포수 모델의 단점을 보완한 점진적 개발방법 3) 시제품의 개발 타당성 검토 후, 시제품을 폐기하거나 프로젝트 자체를 취소하는 경우도 있음 이 경우 시제품 개발 비용 손실(낭비)
프로토타이핑 모델의 개념도 및 장/단점 가. 프로토타이핑 모델의 개념도

나. 프로토타이핑 모델의 장/단점

장점 단점 사용자의 의견이 반영이 잘됨, 사용자 요구사항 도출이 용이 오해, 기대심리 유발, 프로토타입을 최종결과물로 오해 사용자가 더 관심을 가지고 참여할 수 있고 개발자는 요구를 더 정확히 도출할 수 있음 관리가 어려움(중간 산출물 난해) 사용자와의 의사소통 원활 중간단계 산출물 문서화 어려움 시스템 이해와 품질이 향상 폐기 시 비경제적(Overhead)

프로토타입 모델 프로세스
Horizontal Prototyping(수평적 프로토타입)과 Vertical Prototyping(수직적 프로토타입) 가. Horizontal Prototyping(수평적 프로토타입)의 특징 1) 행동적 프로토타입(Behavioral Prototype) 또는 모형(Mock-up) 이라고도 함 2) 실제 제품이나 서비스가 나오기 전에 사용자 입장에서 만드는 프로토타입 3) 목적 : 명확한 요구사항 파악
의도한 시스템의 특정 행동 탐색
요구사항의 구체화
Missing, Wrong, Unnecessary 기능 판단
개발자의 구현방법을 사용자가 평가한 후 Alternative use case, 누락 process step, 과거에 발견하지 못한 Exception Condition 등을 찾아냄 4) 구현 방법 : 사용자와 인터페이스 하고자 하는 화면의 외관만을 보여주고 가능한 Navigation 을 파악 나. Vertical Prototyping(수직적 프로토타입)의 특징 1) 구조적 프로토타입(Structural Prototype) 또는 개념검증(Proof of concept) 2) 기능적, 기능을 완벽하게 다 구현해서 보여주는 프로토타입 3) 목적 : 기술적 타당성 평가
알고리즘의 최적화
제안데이터베이스 스키마 평가
핵심적인 요구사항의 시험 4) 구현 방법 : 운영환경에서 목표시스템과 유사한 결과를 개발하여 평가
프로토타입 유형별 적용 방안

유형 구분 적용방안 수평적 UC 및 기능요구사항 명확화 핵심 UC 구현 구체화 누락 기능 파악 우선순위를 토대로 추가적인 UC 구현 사용자 인터페이스 기준 파악 웹 사이트 개발 및 정렬 신속하게 변화하는 비즈니스요구에 따라 시스템 변경 수직적 기술 타당성 입증 핵심 클라이언트/서버 기능 및 커뮤니케이션 레이어 구현 및 발전 핵심 알고리즘 구현 및 최적화 성능 테스트 및 조율

프로토타이핑 모델의 문제 점 및 해결방안 가. 프로토타이핑 모델의 문제점 1) 최종 결과물에 대한 오해 및 기대 심리 유발 가능성 2) 프로젝트 관리가 느슨해질 가능성 3) 평가 후 프로토타입 폐기 시 비경제적임 4) 산출물 문서화에 소홀해져 문서관리 부실화 가능성 나. 프로토타이핑 모델의 문제점 해결 방안

관점 문제점 해결방안 개발자 시간낭비라는 인식 의사소통의 중요성 교육 관리자 프로젝트 관리 부실화 체계적 개발체제 및 관리도구 도입 사용자 요구사항의 신속한 적용 기대 프로토타입과 최종 결과물의 차이를 명확히 인지토록 설명/교육

SW품질 향상을 위한 반복적 개발(iterative development) 모델 개요 가. 반복적 개발(iterative development) 모델 개념
사용자의 요구사항 일부분 혹은 제품의 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델(폭포수+프로토타입 모형, 각각의 Iteration은 mini-Waterfall 개념)
처음부터 시스템 전체의 기능을 대상으로 하되 릴리즈 할 때마다 기능을 더 완벽히 개발하는 형태 나. 특징
재사용, 객체지향, RAD 모형의 기반 역할
폭포수 모델, 프로토타입 모델, 나선형 모델의 집합
진화형(Evolution Model) 개발 모델 가. 진화형 모델의 정의
시스템이 가지는 여러 구성요소의 핵심 부분을 개발한 후, 각 구성요소를 개선/발전시켜 나가는 개발 모델 나. 진화형 개발 모델의 특징
다음 단계로의 진화를 위해 전체 진화 과정에 대한 개요가 필요
시스템의 요구사항을 사전에 정의하기 어려운 경우, 프로토타입을 만들고 이를 다시 분석하여 요구사항을 진화시켜 나가는 방법
프로토타입은 재사용을 전제로 함
증분 설계가 다음 설계에 반영됨 다. 진화형 모델의 프로세스
1단계 진화 : 시스템의 각 구성 항목의 핵심 부분을 포함하는 최소의 시스템 개발
2단계 이후 진화 : 이전 단계의 시스템을 개선하게 됨
예 : 워드프로세스를 개발할 때 릴리즈 1에 입력, 편집, 포매팅 기능이 기본적으로 가능하게 하고 릴리즈 2에서는 같은 기능이지만 성능을 향상한다든지 기능을 개선
점증적 개발 모델(Incremental Development Model) 가. 점증적 개발 모델의 개념
폭포수 모델의 변형이며 소프트웨어의 구조적 관점에서 하향식 계층구조의 수준별 증분을 개발하여 이들을 통합하는 방식
요구분석서에 나타낸 시스템을 기능별로 여러개의 서브시스템으로 나누고 기능만을 포함한 서브시스템을 릴리즈하고 다음에 새로운 기능을 추가해 나가는 형태 나. 점증적 개발 모델의 특징
폭포수모델의 변형 : 프로토타입 모형의 반복개념을 선형순차 모델 요소들에 결합
프로토타입과 같이 반복적이나 각 점증이 갖는 제품인도에 초점(요구사항 명확시 사용)
규모가 큰 개발 조직일 경우 자원을 각 증분 개발에 충분히 할당할 수 있어, 각 증분의 병행 개발을 통해 개발 기간을 단축시킬 수 있음.
과도한 증분 및 병행 개발일 경우 위험, 증분 개발 활동 간의 조율에 많은 노력 필요 다. 점증적 개발 모델의 프로세스
첫 번째 점증은 위험이 높고, 검증도 안 되고 경험이 없는 기술 아키텍처 전체를 대상으로 하도록 하며, 기술진이 마감일까지 제품을 완전하게 구현할 수 없을 때 유용함
예 : 워드프로세스를 개발할 때 릴리즈 1에 문서의 입력 기능을 완성하고 릴리즈 2에 편집기능을 추가하며 릴리즈 3에 다양한 글씨체와 서식을 사용할 수 있도록 포매팅 기능을 추가
점증형 개발모델과 진화형 개발모델의 비교

항목 점증형 모델 진화형 모델 정의 - 폭포수 모델에 반복적 수행 개념을 결합하여, 증분을 반복하여 개발하고 이를 통합하여 최종 시스템을 구현하는 개발모델 - 핵심 요구사항을 중심으로 개발한 후, 추가적인 요구사항에 대한 기능을 추가 하여 발전 시켜 나가는 방식의 모델 특징 - 병행 개발이 가능 - 요구사항이 명확할 경우 적합 - 요구사항이 개발 초기에 불분명할 경우 적합 - 전체 진화 과정에 대한 Release 계획 필요 장점 - 새로운 시스템에 대한 충격의 완화 - 점진적 통합을 통해 후반 통합의 충격 완화 - 시스템의 완성도를 점진적으로 향상 - 불완전한 요구사항에 대응 가능 단점 - 다수의 빌드 관리의 부담 - 변화되는 사용자 요구사항에 효과적으로 대응이 어려움 - 프로젝트 비용 및 일정 증가 가능성 - 다수의 버전 존재

1 위험 최소화를 위한 진화적 프로타이핑, 나선형(Spiral) 모델 개요 가. 나선형 모델의 정의 - 시스템을 개발하면서 생기는 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발하는 모델(대형 시스템이나 최초 개발 모델 시 Prototype을 지속 발전 후 최종 개발 완료) - 위험 최소화의 목적 - 폭포수와 프로토타이핑 모델의 장점에 위험 분석을 추가한 모델 - 대규모 개발 프로젝트나 국책 사업에 적합한 모델 나. 나선형 모델의 특징

특징 내용 위험관리 - 위험에 대한 식별 및 대응계획을 통한 위험 축소 방안 수립 - 위험은 행위의 결과에 대한 불확실성에서 초래 - 고위험(High-Risk)은 일정 및 비용의 초과 부담 유발 요구사항 식별용이 - 사용자 요구사항에 대한 이해가 용이하고 요구사항을 쉽게 추가 가능 이를 통해 위험의 최소화 가능 대규모시스템 적합 - 사용자 요구사항 식별이 용이하고 위험관리를 통해 대규모시스템 및 위험부담이 큰 시스템에 적합 프로젝트 관리 어려움 - 점진적인 프로세스로 인해 프로젝트 관리가 어렵고 복잡하여 개발시간 장기화 가능성 존재 - 프로젝트 산출물에 대한 관리의 어려움 및 위험관리 전문가가 반드시 필요

다. 등장배경 - 폭포수 모델의 문제 파악 지연/요구 분석 어려움/순차 진행에 따른 유연성 극복 - 위험 요소에 대한 선행 개발 여부에 따른 향후 개발 필요성 대두 2. 나선형 모델 프로세스 모형 및 프로세스 가. 나선형 모델 프로세스 모형

나. 나선형 모델 프로세스 - 계획수립->위험분석->개발->고객평가의 4단계를 가짐

단계 설명 계획수립 (Planning) 목표, 기능 선택, 제약 조건의 결정 요구사항을 모으고 프로젝트 계획수립 나선형 사이클의 시작은 성능, 기능을 비롯한 시스템의 목표를 규명하는 것에서 시작 시스템의 목표와 제약 조건에 대한 차선책이 평가, 고려될 수 있음 이러한 평가과정은 프로젝트 위험의 원인을 규명하는데 효과적으로 사용 위험분석 (risk analysis) 기능 선택의 우선순위, 위험 요소의 분석 초기 요구사항에 근거하여 위험을 규명 정보를 찾아내는 활동을 통하여 불확실성과 위험을 줄여나갈 수 있음 프로젝트를 ‘계속 진행할 것인지’, 또는 ‘중단할 것인지’를 결정 개발 (engineering) 선택된 기능의 개발 위험 분석 결과를 기반으로 다음 개발단계의 개발 모델(패러다임)을 결정 시제품을 개발하거나 최종 제품을 만드는 과정 평가 (evaluation) 개발 결과의 평가 고객에 의해 시스템에 대한 평가가 이루어지고, 고객은 시스템의 수정을 요구 엔지니어링의 결과는 시뮬레이션 모델, 시제품, 또는 실제 시스템일 수 있음, 고객의 평가에 의하여 다음 결과물을 계획

나선형 모델 장/단점 및 비교 가. 나선형 모델 장/단점

장점 단점 - 대규모 시스템 개발에 적합 - 반복적인 개발 및 테스트 - 한 사이클에 추가 못한 기능은 다음 단계에 추가 가능 - 정확한 사용자 요구사항 파악 - 비용이 많이 들고 시간이 오래 걸리는 큰 시스템을 구축해 나가는데 가장 현실적인 접근방법. - 성과를 보면서 조금씩 투자하여 위험 부담을 줄일 수 있는 이상적인 방법 - 정확한 사용자 요구 사항 파악/ 위험 부담 감소/ 품질 확보/대규모 시스템에 적합 - 관리가 중요 - 위험 분석이 중요 - 새로운 모형 - 프로젝트 개발에 많은 시간이 소요 - 관리가 중요하나 매우 어렵고 개발시간이 장기화 될 요지 있음 - 많은 고객을 상대로 하는 상업용 제품에 적용하기 어려움 - 프로젝트 개발에 많은 시간 소요 - 프로젝트 관리에 어려움(복잡함) / 위험관리의 능력에 따라 성공 여부에 영향 - 다수 고객 상대의 상용 제품 개발에는 부적합

나. 나선형 모델 및 폭포수 모델 비교

구분 나선형 모델 폭포수모델 개념 - 프로토타입 + 폭포수모델+ 위험관리 추가된 모델 - 분석/설계/개발/유지보수가 순차적으로 진행되는 모델 프로세스 - 점진적, 반복적 개발 프로세스 - 순차적, 하향적 개발프로세스 장점 - 계획과 요구분석 후 위험분석. - 요구사항의 추가가 용이 - 품질보증도가 높음 - 유연성 - 단순하고 이해하기 쉬움 - 이전단계가 종료되어야 다음단계 진행 가능 - 피드백 절차 필요함 단점 - 프로세스가 복잡하여 프로젝트관리 어려움 - 리스크관리 능력에 따라 프로젝트 성공 여부가 결정됨 - 반복단계가 어려움 - 프로젝트 현실과의 괴리 - 요구사항 변경 시 대처 어려움

다. 나선형 모델 및 애자일 방법론 비교

구분 나선형 모델 애자일 방법론 계획 수립의 상세수준 각 단계별로 상세한 세부 계획 수립 다음 반복주기에 대해서만 상세한 계획 수립 요구 사항의 베이스라인 초기 요구 사항에 대한 Baseline을 설정 요구 사항에 대한 베이스라인 설정을 강조 하지 않음 아키텍처 정의방법 모델과 사양을 보다 상세화하는 과정을 통해 애플리케이션과 데이터 아키텍처를 초기에 정의하고자 함 실제 개발된 기능 구현을 통하여 빠른 시간 내에 아키텍처의 실현가능성을 증명해 보이고자 함 테스트 방법 특정 기능이 구현되고 나서야 단위, 통합, 시스템으로 확장해 나가는 방식 잦은 “개발-테스트” 주기를 통하여 많은 시간과 비용이 들어가기 전에 기능을 검증함 표준 프로세스 적용 개발에 들어가기 전에 표준화된 프로세스를 제정하는 것을 중요하게 여김 정의되고 반복적으로 수행되는 프로세스를 강조하지 않는 대신 잦은 inspection을 토대로 프로세스를 개발에 유연성 적용 강조 포커스 계획, 아키텍처(계획된 프로세스) 환경 변화(경험적 프로세스) 품질측면 프로세스 준수 고객 만족 동인(動因) 계획 주도 고객주도 성공요소 경영층 지원, 인프라 구조 고객과 관계 변화에 대한 태도 위험으로 인식 수용과 포용 위험에 대한 태도 Reactive(수동적) Proactive ( 능동적 ) 적용 대규모 시스템에 적합 중소형 시스템에 적합

V 모델 가. V 모델 정의
폭포수 모델에 시스템 검증과 테스트 작업을 강조 나. V 모델 프로세스
V 모델 장/단점 및 적용 분야 가. V 모델 장/단점
장점 : 모든 단계에 검증과 확인 과정이 있어 오류를 줄일 수 있음
단점 : 생명주기의 반복을 허용하지 않아 변경을 다루기가 쉽지 않음 나. V 모델 적용분야
높은 신뢰성이 필용한 응용분야(의료 제어 시스템, 원전 제어 시스템) □ 다중 V-모델 • 다중 V-모델은 임베디드 시스템을 개발할 때 요구되는 수명주기를 3가지의 연속적인 V-형태, 즉 모델, 프로토타입, 최종 제품으로 구분하여 제시한 것 • 3가지 개발주기 각각은 설계, 구축, 테스트 활동을 포함하고 있으며 각각이 완전한 V-개발주기를 따르고 있음

일정중심 설계 모형의 개요 가. 일정중심 설계 모형의 정의
일정중심 설계 모형은 SW생명주기 모형중 정해진 일정에 SW를 출시하기 위한 모형
단계적으로 여러 차례의 반복적인 Cycle을 거치면서 일정에 맞추기 위하여 변형된 모델 나. 일정중심 모형의 특징
우선순위 기초 : 사용자 요구에 대해 우선순위를 정하여 이를 기초로 각 Cycle 계획
반복적 Cycle : 단계적 여러 차례 Cycle을 거침
일정 중심 : 일정을 맞추기 위한 출시 계획
일정중심 설계 모형의 개념도 및 장/단점 가. 일정중심 설계 모형의 개념도
사용자 요구사항에 기초하여 일정 중심의 설계 모형 나. 일정중심 설계 모형의 장/단점 1) 장점 : 초기 단계 중요한 기능들의 설계, 구현 후 상대적으로 덜 중요한 기능은 나중에 구현함으로써 일정 조절 가능 2) 단점 : 우선순위가 낮아 출시에 포함되지 않을 기능의 분석, 설계에 시간 낭비 발생 다. 반복적 개발 모형과의 차이점
단계적으로 여러 차례 반복적인 Cycle을 거친다는 점에서 유사
일정중심 모형은 최종 목표와 출시가 명확하지 않은 상태로 시작하고 정해진 일정에 맞추기 위해 중간에 중단할 수 있다는 점에서 차이점
일정중심 모형의 적용에 적합한 프로젝트 가. 소프트웨어 제품의 출시 날짜가 매우 중요한 경우에 적합한 모형 나. 목표 일정을 달성할 수 있을지 불확실 한 경우 위험을 면할 수 있음

RAD(Rapid Application Development) 모형의 개념
아주 짧은 개발주기 동안 소프트웨어를 개발하기 위한 선형 순차적 프로세스 모델
사용자 요구사항 일부분, 제품 일부분을 반복적으로 개발하여 최종 제품을 완성하는 방식
RAD 모형의 특징
도구활용(CASE, 재사용 Repository) 및 컴포넌트 기반의 접근방법을 통해 빠른 개발
시스템의 적절한 모듈화가 전제 : 컴포넌트를 사용해 빠르게 폭포수 모델 적용가능
사용자의 적극적 참여와 프로토타이핑 사용
소요기간 : 60-90일 정도의 짧은 기간
기술적 위험이 적고 빠른 개발이 요구될 때 적합
RAD모형이 적합하지 않는 경우
시스템이 적절하게 모듈화 될 수 없는 경우
고성능이 요구되어 부분적으로 시스템 성능이 조율되어야 하는 경우
기술적이 위험이 높은 경우
RAD모형의 개발절차
분석(JRP) : Joint Requirement Planning, 비즈니스/데이터/프로세스 모델링
설계(JAD) : Joint Application Design, 사용자참여 공동설계
구축/운영 : CASE, RDB, 4GL 관련기술을 이용한 시스템구축
RAD의 장/단점 가. RAD의 장점
검증된 컴포넌트가 존재하고, 시간적 제약사항이 존재시 접근 가능한 방법
요구사항의 완전한 이해와 명확한 PJT범위 설정시 신속개발 및 기능구현가능 나. RAD의 단점
책임감 있는 구성이 없을 경우 위험
적절한 모듈화(컴포넌트), 가능성 전제
요구사항 변화가 심하고, 기술적 위험이 크고, 고성능이 요구되는 시스템에 부적절
전통적인 생명주기와 RAD의 비교

구분 RAD 모델 전통적인 생명주기 모델 목표 핵심 요구사항만족, 시간단축 고품질 구현 개발인원 소규모, 사용자+개발자 대규모, 개발자위주 분석/설계 개략적인 분석/설계 완벽한 분석/설계 기법 JRP, JAD, Time-Boxing 데이터모델링, 프로세스 모델링 특징 사용자 지속적 참여 순차적 접근 툴사용, 적정규모 하향식 접근

RAD 사이클
개발자와 고객 사이에 피드백 루프를 둬서 유연성을 증가시킴
RAD모델 기반의 Agile 대표 개발방법론

종류 특징 비고 XP 테스트 중심, 4가지 가치와 12개 실천항목을 가지고 1~3반복 가장 주목받고 있음 개발관점 SCRUM 프로젝트를 스프린트로 분리, 팀은 메일 스크럼 미팅으로 계획수립 Iteration 계획과 Tracking에 중점

I. Increment를 기반으로 한 반복적 개발 프로세스, 클린룸 모델의 개요 가. 클린룸(Clean room)의 정의 - 시스템의 핵심 영역을 최초로 Increment로 개발하여 사용자에게 피드백하여 새로운 요구사항을 도출하거나 개발 계획을 수정하여 반복해서 증가분 소프트웨어를 개발, 시스템에 추가하는 프로세스 모델. - IBM의 Mills [MIL87] [DYE92]에 의해 고안된 모델 나. 클린룸 모델의 특징 - 반복적 개발 프로세스 모델. - 핵심 영역을 최초로 실행 가능한 프로토타입 Increment로 개발. - 시스템 내에서의 중요도, 이용빈도, 사용자의 Feedback 평가 등으로 Increment 개발 순서가 결정 - 3가지의 블랙박스, 상태박스, 클리어 박스로 구성. II. 클린룸 모델의 개발프로세스 가. 클린룸 모델에 의한 점진적 개발 개념

나. 클린룸 모델에 의한 개발 프로세스-1

(Richard C. Linger Carmen J. Trammell(1996), Cleanroom Software Engineering Reference Model Version 1.0, pp16) 다. 클린룸 모델에 의한 개발 프로세스-2

우선 개발하는 시스템에 대한 요구분석
기능적인 명세(사양)와 이용 시나리오를 기술
순차적으로 기능을 추가하여 갈 것인가의 점진적(Incremental)계획서를 작성
개발은 점진적 계획서에 따라서 증가분한 인크리먼트마다 추가 기능의 설계와 검증, 테스트 케이스의 작성을 수행하면서 계획적으로 진행 III. 인크리먼트 명세의 상세화와 검증 방법 가. 검증 방법
품질 검사와 기능의 검증을 증가분 소프트웨어에 대해서만 검증 실시
시스템 개발자가 설계 리뷰에 있어서 증가분 소프트웨어 부분에 형식적인 검증 방법을 엄밀하게 적용하는 현실적인 방법을 사용

방법 내용 박스 구조 분석에 의한 단계적 상세화 인크리먼트 부분의 설계 명세가 정확한지 여부 검증 함수등가성에 기초한 검증 상세화한 것이 정확한지의 검증 이용 시나리오에 의한 통계적 테스트 입력으로부터 출력으로 변환되는 과정에 관심 명세를 입력과 출력과의 관계로 관련지어 수행하는 블랙박스로 취급하여서 서서히 입력으로부터 출력으로 변환되는 과정에 관심을 두고 상세화하여 나가는 분석 방법

나. 박스 구조 분석 1) 블랙박스 - 명세를 입력으로부터 출력을 얻기 위한 기능을 구체적으로 다루지 않고, 추상적인 블랙박스로 표현 - 입력으로부터 출력에 이르기까지의 데이터 흐름을 중심으로 하여 그 사이에 데이터를 어떻게 변환할지의 기능을 표현한 블랙박스의 일련의 조합에 의하여 기술

2) 상태 박스 - 블랙박스를 자세하게 하여 내부의 기능을 표현하기 위하여 다시 한번 내부 상태를 표시하는 데이터나 내부 데이터를 추가하여 표현 - 내부에서 사용하는 데이터의 변환을 수행하는 기능을 다시금 블랙박스로서 기술 - 블랙박스에서 기술한 입출력과 상태박스는 매칭되어야 함

3) 클리어 박스 - 상태 박스에 다시금 제어의 흐름을 추가 - 내부 블랙박스와 함께 블랙박스 사이에서의 제어 흐름 및 시간적인 의존 관계를 기술하여 자세하게 기입 - 상세화의 최종 단계에서 존재하는 블랙박스는 기존의 소프트웨어 컴포넌트 이외의 것이어서는 안됨

다. 함수등가성 1) 명세를 입력과 출력과의 대응관계를 정의하는 함수로서 다루어, 명세를 자세하게 한 것이 입출력관계와 기능에 있어서 원래의 명세와 등가(等價)임을 판정하는 기준 2) 함수 등가성의 대상 - 구조화 프로그래밍(Structured Programming)에 있어서의 4가지 제어구조, 즉 순차, 분기, 선택, 반복의 제어 구조 - 4가지 제어 구조로 기술한 내용과 함수적으로 등가인가를 설계자가 리뷰함으로서 검증 3) 리뷰 실시 시 초점 - 검증하는 명세 부분에서 처음 성립한 사전 조건과 나중에 성립한 사후 조건이 변하지 않았는가 - 명세 부분의 논리적인 구조로부터 원시 코드로의 변환이 논리적인 추론에서 적당한가

명세와 원시 코드의 기본적인 함수 등가 관계를 검토

계획

상향식(bottom-up) 방법
프로젝트에 수행될 작업을 작은 단위로 나누고 각 작업에 소요될 기간이나 노력을 예측
독립된 작업 사이에 병행하여 수행할 경우 단축되는 기간을 계산하면 전체 소요 기간이나 노력을 구할 수 있음
작은 단위 작업에서 출발하여 전체 프로젝트의 기간을 예측
프로젝트를 위한 소작업에 소요되는 기간을 구하고 여기에 투입되어야 할 인력과 투입 인력의 참여도를 곱하여 최종 인건비용을 계산
WBS, CPM 네트워크, 간트차트
하향식(top-down) 방법
프로그램의 크기와 노력 사이의 관계를 나타내는 수학적 모델을 사용
시스템의 규모를 과거의 경험, 구현 언어, 재사용 비율 등을 고려하여 예측하고 이를 비용 모델(cost model)에 대입하여 노력이나 기간을 산출
전체 규모로부터 기간을 예측하여 정하고 이를 바탕으로 소단위 작업의 노력을 추정
프로그램의 규모를 예측하고 과거 경험을 바탕으로 예측한 규모에 대한 소요 인력과 기간을 추정(FP, LOC, Man-Month, COCOMO)
프로젝트 일정 계획 작업 과정
소프트웨어 프로젝트 계획에서 일정계획을 위한 작업순서
작업분해->작업 소요시간 및 우선순위 결정->CPM 네트워크 작성->CP(Critical Path) 추출->일정표 작성

사용자 관점의 정량적 SW 규모 산정기법 FP 개요 가. FP(Function Point)의 정의
SW규모를 트랜잭션 기능, 데이터 기능의 수와 복잡성을 기초로 하여 규모를 산정하는 방식
사용자 관점에서의 논리적 기능량을 측정 나. 기존 Loc 방법의 문제점
예측의 어려움 : SW개발 초기에 프로그램 라인수를 예측하기 어려움
프로그램 언어 : 동일한 기능을 하는 SW라도 개발언어에 따라 SW라인수는 크게 다름
환경요소 : 기능은 동일하여도 3tier C/S, 1tier C/S, web 환경에 따라 비용 산정의 어려움 발생 다. FP 산정방식 유형

구분 정규법 간이법 목적 상세한 기능점수 측정 개략적인 견적 산정 측정항목 데이터 기능, DET/RET 데이터 기능 트랜잭션 기능, DET/FTR 트랜잭션 기능 복잡도 적용 기능별 복잡도 적용 평균 복잡도 적용 적용시기 SW개발∙유지보수 규모 산정시 (분석/설계 단계 이후) 예산수립/제안단계 적용 가능 산정자료 불충분 및 산출 기능점수 검증

FP 개념도 및 구성요소 가. FP 개념도

나. FP 구성요소 (1) 데이터 기능 - 내부논리파일(ILF, Internal Logical File) : 애플리케이션 경계 내에서 유지되는 데이터 및 제어정보 - 외부연계파일(EIF, External Interface File) : 애플리케이션 경계 밖에서 유지되는 데이터 및 제어정보 (2) 트랜잭션 기능 - 외부입력(EI, External Input) : 사용자 입력기능(등록, 수정, 삭제 포함) - 외부출력(EO, External Output) : 사용자 출력기능(처리 로직을 포함) - 외부조회(EQ, External Query) : 사용자 조회기능(처리 로직 없이 데이터를 그대로 보여주는 경우) 3. FP 측정 단계 가. FP 측정 흐름도

나. FP의 측정 단계 (1) 측정유형 결정 - 개발FP : 프로젝트 종료시점, 사용자 인도시점의 S/W - 개선FP : 추가, 수정, 삭제와 같은 변경부분에 대한 규모측정 - 애플리케이션FP : 사용자가 사용하는 S/W의 현재상태의 기능 (2) 측정범위와 애플리케이션 경계식별 - 현재 개발 또는 변경할 S/W에 대한 전체범위를 결정 - 각 애플리케이션의 경계 분류 (3) 데이터 기능 측정 - ILF(Internal Logical File)와 EIF(External Interface File) 식별 - ILF, EIF 식별 후, 각각 복잡도와 기여도를 결정하여 데이터기능점수 도출 - 복잡도 산정은 DET(Data Element Type)와 RET(Record Element Type)를 통해서 이루어짐 - DET : 유일하고 사용자 식별가능하며, 비반복적 필드 - RET : ILF나 EIF 안에서 사용자가 식별이 가능한 데이터요소의 서브그룹 [데이터 기능 측정 예시]

(4) 트랜잭션 기능 측정 - 단위 프로세스를 식별 - 각 단위 프로세스 별 EI/EO/EQ 분류 - 각각 복잡도와 기여도를 계산하여 트랜잭션 기능점수 계산 - DET와 FTR(File Transfer Reference)을 통해 복잡도 계산 - FTR : 애플리케이션에서 참조하는 ILF나 EIF의 수 (5) 미조정 기능점수(UFP) 결정 - 데이터 기능점수 + 트랜잭션 기능점수 (6) 조정인자(VAF) 결정 - 14개의 일반시스템특성(General System Characteristics) 질문에 대한 합계에 따라 결정 - 각 항목은 0~5까지의 영향도로 이루어짐 - 미조정 기능점수 값을 35% 조정할 수 있음 - VAF = (총 영향도(TDI)0.01)+0.65 (7) 조정기능점수(AFP) 결정 - UFP(미조정 기능점수) X VAF(조정인자) 다. 14개 일반시스템 특성 및 영향도 (1) 14개 일반시스템 특성 - 데이터 통신(Data Communication) - 분산데이터 처리(Distributed Data Processing) - 시스템 성능(System Performance) - 자원제약 정도(Heavily Used Configuration) - 트랜잭션 비율(Transaction Rate) - 온라인 데이터 비율(On-Line Data Entry) - 최종 사용자 효율성(End-User Efficiency) - 온라인 갱신(On-Line Update) - 처리 복잡도(Complex Processing) - 재사용성(Reusability) - 설치용이성(Installation Ease) - 운영용이성(Operational Ease) - 다중설치성(Multiple Sites) - 변경용이성(Facilitate Change) (2) 일반시스템 특성 영향도 - 0(전혀 무영향) - 1(우연한 경우) - 2(조금 영향) - 3(평균) - 4(상당한 영향) - 5(강한 영향) 4. FP의 적용범위 및 효과 가. 적용 범위 - 벤치마킹 조사, 개발비용 산정, 프로세스 개선 분석 - 유지보수 비용산정, 아웃소싱 계약, 품질비용 산정 - 국내에서는 신규개발사업의 비용산정 용도로 사용 나. 효과 - 패키지를 포함한 모든 기능을 측정하여 응용패키지의 규모를 알 수 있음 - S/W 제품별 품질과 생산성 분석을 위한 측정도구로 활용 - S/W 개발, 유지보수에 요구되는 비용, 자원을 산정할 수 있음 4. FP, Man/Month, Loc 비교

구분 FP Loc Man/Month 정의 사용자 관점에서 업무적 요구기능을 측정하는 방식 각종 지시 명령을 기술한 최소 단위를 측정하는 방식 투입되는 인원에 대한 인건비를 측정하는 방식 산정방법 사용자의 요구사항을 기준으로 식별해 규모를 산정 최소 명령단위인 문장의 수를 측정 사용자 과거 경험을 기준으로 투입되는 인력의 규모를 산정 난이도 측정 기능 구현에 따라 난이도 적용 가능 난이도 적용 불가 프로젝트 전체 공정에서 측정 가능 장점 일관성 및 정확성 유지 가능 물리적인 라인수를 측정 하므로 산정이 용이하고 산정 자동화 가능 투입되는 인력을 기준으로 측정 하므로 산정이 용이 산정근거가 명확하고 논리적임 논리적이고 사용자 중심으로 측정하므로 발주자 관점에서의 규모산정 단점 규모 산정을 위한 전문성 필요 개발자 역량에 따라 규모가 달라질 수 있음 경험치가 없을 경우 산정에 어려움 정확한 측정을 위해 세부 요구사항 도출이 선행되어야 함 SW규모를 단순히 라인수로 산정 논리적인 산출근거 도출이 불가해 비용산정이 불투명함

기능점수 단가는 1개 기능점수 개발(분석, 설계, 구현, 시험)에 소요되는 비용 문) 기능점수(Function Point) 측정에 대하여 아래의 내용을 근거로 각 질문에 답하시오. [업무기능요건]
가. 인사담당자가 인사기본정보(사원DB,부서DB)를 관리한다. 나. 인사담당자가 임직원의 직무정보(사원DB,직무DB)를 산업인력관리공단의 표준직무DB와 연계하여 관리한다. 다. 인사담당자가 부서별 각종 최신 통계자료(사원DB, 직무DB, 부서DB)를 조회 출력한다. 1) 기능점수 산출방법의 간이법과 정규법의 차이점을 비교 설명하시오. 2) 간이법을 적용하여 주어진 [업무기능요건]에 대한 트랜잭션 기능(Transaction Function)과 데이터 기능 (Data Function)을 산출 하시오. 3) 간이법을 적용하여 주어진[업무기능요건]에 대한 기능점수를 산출하시오.(복잡도는 ISBSG의 평균데이타를 이용할 것)

답) 간이법 I. 기능점수 산출방법의 간이법과 정규법의 차이점을 비교 설명하시오.

구분 정규법 간이법 개념 논리적인 설계를 바탕으로 한 각 기능의 속성을 정의하여 기능별 복잡도 매트릭스에 의한 기능점수 산정 방식 개략적인 사용자 요구사항을 바탕으로 기능점수를 도출하여 평균복잡도에 의한 기능 점수 산정 방식 사용시기 상세한 기능점수 측정 프로젝트 초기에 측정 사용목적 SW 분석, 설계, 개발, 유지보수의 개발범위 및 일정, 원가 산정 예산수립, 제안서 견적 산정, 계약의 SW 사업대가 산정 측정항목 - 데이터 기능 및 DET, RET수 도출 - 트랜잭션 기능 및 DET, FTR 식별 - 데이터 기능 - 트랜잭션 기능 복잡도 기능별 복잡도 매트릭스 평균 복잡도

II. 간이법을 적용하여 트랜잭션 기능과 데이터 기능을 산출하시오. 가. 데이터 기능점수 = 내부논리파일 + 외부연계파일 (기능점수) - 내부논리파일기능점수 = 내부논리파일(ILF) 개수 X (평균)ILF복잡도가중치 - 외부연계파일기능점수 = 외부연계파일(EIF) 개수 X (평균)EIF복잡도가중치 => 27.7 = (3 X 7.4) + (1 X 5.5) 나. 트랜잭션 기능점수 = 외부입력+ 외부출력 + 외부조회 (기능점수) - 외부입력 기능점수 = 외부입력(EI) 개수 X (평균)EI복잡도가중치 - 외부출력 기능점수 = 외부출력(EO) 개수 X (평균)EO복잡도가중치 - 외부조회 기능점수 = 외부조회(EQ) 개수 X (평균)EQ복잡도가중치 => 9.2 = (0 X 4.3) + (1 X 5.4) + (1 X 3.8) III. 간이법을 적용하여 기능점수를 산출하시오. (ISBSG 평균데이터 이용할 것) 가. 미조정 기능점수(UFP) = 데이터 기능점수 + 트랜잭션 기능점수 => 36.9 = 27.7 + 9.2 나. 조정인자 값(VAF) = {(항목1 가중치(0~5) + …… + 항목14 가중치(0~5)) X 0.01 ) + 0.65 => 1.07 = { (3 + ... + 3) X 0.01 } + 0.65 (각 항목의 가중치는 3으로 가정) 다. 조정 기능점수(AFP) = 미조정 기능점수(UFP) X 조정인자 값(VAF) => 39.48 = 36.9 X 1.07 IV. 지식경제부 기준의 개발원가를 산출하시오 가. 보정전 개발원가 = 기능점수(UFP) X 기능점수당 단가 => 18,355,056원= 36.9점 X 497,427원 나. 보정계수 - 규모 보정계수 : 0.65 (300FP 미만) - 애플리케이션 유형 보정계수 : 1.0 (업무처리용) - 언어 보정계수 : 1.2 (C# 가정) - 품질 및 특성 보정계수 = 0.025 X 총 영향도 + 1 . (가정)분산처리:1, 성능:1, 신뢰성:1, 다중사이트:1 . 1.1 = 0.025 X (1+1+1+1) + 1 다. 개발원가 = 보정전 개발원가X (규모 보정계수 X 애플리케이션유형 보정계수 X 개발언어 보정계수 X 품질 및 특성 보정계수) 15,748,638원= 18,355,056원 X (0.65 X 1.0 X 1.2 X 1.1) 문) 신규 소프트웨어 개발 프로젝트 계획단계에서 기능점수를 측정하였더니 아래의 [표1]과 같이 기능이 식별되었다. 측정시점에서 신규 개발기능의 세부내용에 대한 개별복잡도 측정이 어려워 평균복잡도 가중치를 적용키로 하였으며, 다른 요구기능은 없다고 가정하고 다음 질문에 대하여 설명하시오 표1) 기능점수 식별예시

구분 기능수(개) 데이터기능 내부논리파일(ILF) 12 외부논리파일(ELF) 6 트렌잭션기능 외부입력(EI) 24 외부출력(EO) 3 외부조회(EQ) 12

표2) 기능점수 평균 복잡도 가중치

유형 내부논리파일 외부연계파일 외부입력 외부출력 외부조회 가중치 7.3 5.4 4.0 5.1 3.8

1) IFPUG의 기능점수 측정 절차를 설명하시오 2) 기능별 평균점수와 개발 기능점수를 구하시오 3) 기능점수 측정의 유의사항과 기능점수 측정결과에 대한 지식화 방안을 제시하시오 답) 간이법 I. IFPUG의 기능점수 측정절차를 설명하시오. II. 기능별 평균점수와 개발 기능점수를 구하시오. 가. 데이터 기능점수 = 내부논리파일 + 외부연계파일 (기능점수) - 내부논리파일기능점수 = 내부논리파일(ILF) 개수 X (평균)ILF복잡도가중치 - 외부연계파일기능점수 = 외부연계파일(EIF) 개수 X (평균)EIF복잡도가중치 => 120 = (12 X 7.3) + (6 X 5.4) 나. 트랜잭션 기능점수 = 외부입력 + 외부출력 + 외부조회 (기능점수) - 외부입력 기능점수 = 외부입력(EI) 개수 X (평균)EI 복잡도가중치 - 외부출력 기능점수 = 외부입력(EO) 개수 X (평균)EO 복잡도가중치 - 외부조회 기능점수 = 외부입력(EQ) 개수 X (평균)EQ 복잡도가중치 => 156.9 = (24 X 4.0) + (3 X 5.1) + (12 X 3.8) 다. 미조정 기능점수(UFP) = 데이터 기능점수 + 트랜잭션 기능점수 => 276.9 = 120 + 156.9 라. 조정인자 값(VAF) = {(항목1 가중치(0~5) + …… + 항목14 가중치(0~5)) X 0.01 ) + 0.65 => 1.07 = { (3 + ... + 3) X 0.01 } + 0.65 (각 항목의 가중치는 3으로 가정) 마. 조정 기능점수(AFP) = 미조정 기능점수(UFP) X 조정인자 값(VAF) => 296.283 = 276.9 X 1.07 III. 지식경제부 기준의 개발원가를 산출하시오 가. 보정전 개발원가 = 기능점수(UFP) X 기능점수당 단가 => 137,737,536원= 276.9점 X 497,427원 나. 보정계수 - 규모 보정계수 : 0.65 (300FP 미만) - 애플리케이션 유형 보정계수 : 1.0 (업무처리용 가정) - 언어 보정계수 : 1.2 (C# 가정) - 품질 및 특성 보정계수 = 0.025 X 총 영향도 + 1 . (가정)분산처리:1, 성능:1, 신뢰성:1, 다중사이트:1 . 1.1 = 0.025 X (1+1+1+1) + 1 다. 개발원가 = 보정전 개발원가X (규모 보정계수 X 애플리케이션유형 보정계수X 개발언어 보정계수 X 품질 및 특성 보정계수) 118,178,806원= 137,737,536원 X (0.65 X 1.0 X 1.2 X 1.1) 문) SW사업대가기준_개정안(지경부고시_제2009-102호)에는 정확한 소프트웨어 개발 산정을 위해 공공기관의 SW개발시에 기능점수산정 방식으로 적용하도록 하였다. 소프트웨어 개발비 산정에 대해서 다음에 대해 설명하시오. 가. IFPUG(International Function Point User Group)에서 정의한 기능점수 점수 산정방식의 특장점과 ILF, EIF, EI, EO, EQ에 대해 설명하시오. 나. 사원정보를 관리하는 업무가 다음 데이터모델을 가질 때 근거하여 데이터기능의 기능형식(ILF)의 수, RET의 수, DET의수와 트랜잭션기능의 FTR과 DET수를 구하라.

다. 위에서 복잡도/보정요소를 반영하여 20FP(점)이 산정되었다(가정). 다음 항목을 반영하여 SW개발비를 산정하시오. - 단가 : 1FP당 600,000원 - 이윤 : 20% - 직접비 : 출장비 : 0.01억, 인쇄비 : 0.01억, 전문가운영비 : 0.02억, 워크샵비: 0.01억 답) 정규법 I. IFPUG에서 정의한 기능점수 점수 산정방식과 특장점과 용어를 설명하시오. 가. FP 점수 산정방식의 특장점 - 사용자관점 : 개발자 관점이 아닌, 사용자 관점에서 SW 규모 측정함 - 기능중심 : 소스가 아닌 기능으로 규모 측정함 - 논리적 단위 : 물리적인 파일, 스크린, 프로그램이 아닌 사용자의 업무기능인 논리관점에서 측정함 - 패키지 측정가능 : 패키지에 대해서도 기능관점으로 측정할 수 있음 - 품질, 생산성 측정도구 가능 - 유지보수 이용 가능 : 유지보수에 비용과 자원 산정 시 활용이 가능 나. FP의 용어설명 - 데이터 요소 유형(Data Element Type, DET) : 사용자가 식별 가능하고, 유일하고 비반복적인 필드 - 레코드 요소 유형(Record Element Type, RET) : 내부논리파일(ILF) 또는 외부연계파일(EIF) 안에서 사용자가 식별 가능한 데이터의 서브그룹으로 2가지 유형이 있음 . Optional, 선택적 서브그룹 . Mandatory, 필수적 서브그룹 - 참조파일유형(File Type Referenced, FTR) : 트랜잭션 기능에 의해 조회되거나 유지되는 내부논리파일(ILF) 또는 트랜잭션기능에 의해 참조되는 외부연계파일(EIF) II. RET의 수, DET의 수와 트랜잭션기능의 FTR과 DET수를 구하라. 가. 데이터 기능

구분 건수 설명 ILF(Internal Logical File) 1 (사원정보) 부양가족은 사원에 딸려있는 부가정보 RET (Record Element Type) 2 사원, 부양가족 DET(Data Element Type) 10 사원번호, 사원이름, 주소, 성별, 나이, 어학점수, 가족주민번호, 가족이름, 직업, (부양가족)주소

참조, 내부논리파일/외부연계파일의 복잡도 및 기능점수 가중치(지경부고시)

구분 데이터요소유형(DET) 복잡도 가중치 레코드요소유형 (RET) 1 ~ 19 20 ~ 50 51 ~ ILF EIF 1 낮음 낮음 보통 낮음 7 5 2 ~ 5 낮음 보통 높음 보통 10 7 6 ~ 보통 높음 높음 높음 15 10

ILF : 사원정보(1), RET(2)/DET(10) Matrix = 7점(데이터 기능점수) 나. 트랜잭션 기능

구분 건수 설명 FTR(File Type Referenced) 1 (사원정보) 부양가족은 사원에 딸려있는 부가정보 DET(Data Element Type) 7 사원번호, 조회버튼, 사원이름, 주소, 주민번호, 가족이름, 레코드 숫자(00명)

참조1, 외부입력의 복잡도 및 기능점수 가중치(지경부고시)

구분 데이터요소유형(DET) 복잡도 가중치 참조파일유형(FTR) 1 ~ 4 5 ~ 15 16 ~ EI 0 ~ 1 낮음 낮음 보통 낮음 3 2 낮음 보통 높음 보통 4 3 ~ 보통 높음 높음 높음 6

참조2, 외부출력/외부조회의 복잡도 및 기능점수 가중치(지경부고시)

구분 데이터요소유형(DET) 복잡도 가중치 참조파일유형(FTR) 1 ~ 5 6 ~ 19 20 ~ EO EQ 0 ~ 1 낮음 낮음 보통 낮음 4 3 2 ~ 3 낮음 보통 높음 보통 5 4 4~ 보통 높음 높음 높음 7 6

EO : 사원정보(1), FTR(1)/DET(7) Matrix = 4점(트랜잭션 기능점수) III. SW개발비를 산정하시오. 가. 조건
FP점수 : 20FP, 단가 : 600,000원/1FP, 이윤 : 20%
직접비 : 출장(0.01억), 인쇄(0.01억), 전문가운영(0.02억), 워크샵(0.01억) 나. 총 SW개발비
개발원가 = FP점수 X 600,000원/FP => 0.12억= 12,000,000원 = 20FP X 600,000원
이윤 = 개발원가 X 이윤(0.2) => 0.024억 = 0.12억 X 0.2
직접비 = 항목 계 => 0.05억 = 0.01억 + 0.01억 + 0.02억 + 0.01억
총 SW개발비 = 개발원가+ 이윤 + 직접비 => 0.194억 = 0.12억 + 0.024억 + 0.05억 IV. 지식경제부 기준의 개발원가를 산출하시오 가. 보정 전 개발원가 = 기능점수(UFP) X 기능점수당 단가 => 9,948,540원= 20점 X 497,427원 => 12,000,000원= 20점 X 600.000원(문제의 단가조건으로 계산) 나. 보정계수
규모 보정계수 : 0.65 (300FP 미만)
애플리케이션 유형 보정계수 : 1.0 (업무처리용 가정)
언어 보정계수 : 1.2 (C# 가정)
품질 및 특성 보정계수 = 0.025 X 총 영향도 + 1 . (가정)분산처리:1, 성능:1, 신뢰성:1, 다중사이트:1 . 1.1 = 0.025 X (1+1+1+1) + 1 다. 개발원가 = 보정 전 개발원가 X (규모 보정계수 X 애플리케이션유형 보정계수 X 개발언어 보정계수 X 품질 및 특성 보정계수) => 8,535,847원= 9,948,540원 X (0.65 X 1.0 X 1.2 X 1.1) => 10,296,000원= 12,000,000원 X (0.65 X 1.0 X 1.2 X 1.1) (문제의 단가조건으로 계산) 라. 이윤 = 개발원가 X 이윤(0.2) => 1,707,169 = 8,535,847원 X 0.2 => 2,059,200 = 10,296,000원 X 0.2 (문제의 단가조건으로 계산) 마. 직접비 = 항목 계 => 5,000,000원 = 0.05억 = 0.01억 + 0.01억 + 0.02억 + 0.01억 바. 총 SW개발비 = 개발원가 + 이윤 + 직접비 => 0.152억 = 15,243,016원 = 8,535,847원 + 1,707,169원 + 5,000,000원 => 0.174억 = 17,355,200원 = 10,296,000원 + 2,059,200원+ 5,000,000원 (문제의 단가조건으로 계산)

WBS 고유 식별자 Code Of Accounts 가. Code Of Accounts의 정의
WBS의 각 요소를 고유하게 식별하는데 사용되는 숫자 또는 알파벳으로 구성된 고유ID, 넘버링 체계
WBS에서의 Code Of Accounts 구성 방법 및 예시 가. WBS Code Of Accounts 구성 방법 [1차 분류]
공통관리(WA), 영업/계약(WB), 착수(WC), 분석(WD), 설계(WE), 구현(WF), 적용(WG), 종료(WH) [2차 분류 - 나머지 분류]
기본 : 각 작업은 순서 별로 1단위씩 증가하여 적용(1, 2, 3, ..., 100, 101, ...)
추가 : 세부 분류 나누어 구성(10.1, 10.2, ...) 나. WBS Code Of Accounts 구성 예시

예시 Code Of Accounts 통합테스트 시나리오 작성 PWF.7.4.3 통합테스트 시나리오가 “통합테스트 시나리오 작성” 과 “통합테스트 시나리오 검증”으로 분할시 “PWF.7.4.3.1", "PWF.7.4.3.2"로 분할 3. 프로젝트 산출물의 기준을 제공하는 WBS의 개요 가. WBS(Work Breakdown Structure)의 정의 - 프로젝트 목표를 단계(Phase), 활동(Activity), 작업(Task) 등 계층적으로 분류하는 것 - 관리와 통제를 목적으로 프로젝트를 식별하고 측정할 수 있는 근원적인 요소로 나누는 계층적 분류구조 - 프로젝트에 소요되는 자원을 배정 또는 산정하는 근거를 제공 - 프로젝트의 목적을 달성하기 위하여 관리 또는 통제의 목적으로 프로젝트의 요소들을 단계별로 작은 단위로 나누어 놓은 관리의 객체 - 프로젝트 범위관리의 산출물로서, 프로젝트 수행 범위를 정의 한다. 또한 적절한 단계까지 분할하여 관리/통제가 가능한 작업패키지 수준으로 상세화하며, 상세화 정도는 프로젝트의 특성에 따라 적절한 수준을 유지 나. WBS의 특징 - 산출물 중심 : 업무범위 통제 및 관리를 위한 명확한 산출물 중심의 관리 - 관리 기능 : 정확한 계획수립과 작업성과를 통제 - 단위성 : WBS의 최하단위인 Work Package를 통해 80시간(2주)내외의 기간으로 분할 - 구성요소 : 고유한 ID 넘버링 체계를 가짐 다. WBS의 목적 - 주요 프로젝트 산출물을 작게 관리 가능한 구성단위로 분해 - 비용, 일정, 자원산정의 정확도향상 - 성과측정과 통제의 기준선 정의 - 명확한 책임과 역할 할당의 용이성 제공 라. WBS 작성의 적정성 판단 기준 - 관리 가능한 수준까지 분할(2주정도, 80시간정도) - 원가와 일정 추정이 가능한 수준까지 분할 - 개인 및 조직에게 일을 할당 해주고 책임을 물을 수 있는 수준까지 분할 (현장에서는 과업 대비표, 요구사항 추적표를 통해 관리) 4. WBS의 작성과 구성요소 가. WBS의 작성원칙과 작성방법

• WBS의 원칙 – 하부 수준의 항목은 상위 수준의 항목의 세분화 – 최상위 수준은 전체 프로젝트 구성 – 첫번째 수준은 통상 프로젝트 생명 주기(PLC) 기반 – 프로젝트 산출물 중심으로 작업 • 작업 항목 분할 지침 – 현실적으로 명확하게 산정할 수 있는 수준 – 더 이상 논리적으로 분할하기 어려울 때까지 – 신속히 완료 가능한 수준(80시간 이내) – 결과와 산출물이 의미가 있을 것 – 작업에 방해를 받지 않고 완료 가능하도록

구분 설명 작성원칙 방법론 이용 원칙, 장기계획 원칙 One-week 원칙, Two-week 원칙, Six-month 원칙 작성방법 전지에 WBS를 Post-it을 이용하거나 프로그램 도구를 이용하여 구성 각 단계에 포함시켜야 할 activity를 팀원이 협의하여 구성 Activity의 총 개수는 범위기술서의 내용을 참조하여 구성 도출해 낸 activity들을 역시 Post-it을 사용하여 적어 붙이거나 프로그램 도구를 이용하여 구성

나. WBS의 구성항목

구성항목 설명 Work Package WBS의 최하위 단위, 통상 80시간 내외의 기간 Code of Account WBS의 고유한 ID 넘버링 체계 WBS Dictionary Work Package의 상세한 내용을 기술 작업의 개요, 일정, 책임자, 예산 등을 기술 WBS분할 적정성 판단기준 각 Work Package별로 일정과 원가를 추정가능한가의 여부

폭포수 생명주기 기반의 WBS 예제 다. WBS의 작성 절차도
프로젝트 수행 계획서 상에 고객과 합의된 범위를 바탕으로 업무를 실행 가능한 최소 단위로 분해하여 일정, 비용 및 산출물을 정의
WBS 작성시 유의 및 고려사항 가. WBS는 일정관리 도구가 아니고, 프로젝트 내부 및 고객과의 의사소통 수단으로 사용하고 PM이 생성하는 것이 아니라 프로젝트 팀에서 생성되어야 함 나. 분할을 상세히 할수록 더 정확한 원가와 일정의 측정이 가능하지만 시간과 비용의 증가를 고려하여 정확성과 비용과의 상관관계를 고려해야 함
WBS 작성절차

단계 구분 설명 WBS요소 나열 WBS요소 나열 프로젝트의 목표와 부합하는 활동과 부합하는 모든 활동과 산출물 나열 프로젝트에서 사용될 테스트 툴이나 관리기법 등이 모두 도출되어야 함 개략설계 프로젝트의 기본적인 흐름 정의 분석/설계/개발/시험 등의 활동 수준으로 상위레벨에 대한 정의 수행 각 단계의 진입 기준/진출 기준과 활동의 범위 정의 수행 WBS 요소의 선택 앞서 정의된 WBS 요소를 개략 설계에서 정의한 단계와 연관 지음 상세설계 앞서 정의된 WBS 요소와 개략 설계를 상세화하는 것으로, 보다 세부적인 구성단위까지 분할 반복적으로 수행하여, 최소 단위까지 분할하는 것이 목표 WBS Dictionary 구성 작성된 각 WBS 항목의 재활용을 위함 각WBS 항목에 공유 ID와 구체적인 설명을 첨부하여 PWBS에서 CWBS를 산출하는 경우 재구성이 용이하도록 함 이후 프로젝트 구성 시 사전 정의된 활동을 재활용 할 수 있음 WBS후속 작업 WBS제안 작성된 WBS에 회사의 산정을 적용한 비용 산정 후 이에 대한 구체적인 프로젝트 제안 수행 WBS계약 프로젝트 계약 시 제안된 WBS를 토대로 재수정한 계약 WBS 첨부되며, 이를 SOW(Statement Of Work : 작업 목록)으로 정의 WBS관리 프로젝트 수행 중에 하는 관리 진척관리를 통해 진척 상황에 따라 추가작업을 정의하거나 세분화하는 과정

PMI 9개 활동 영역에서의 WBS 활용 가. PMI 9개 활동 영역에서의 WBS활용

구분 설명 통합관리 (Integration) WBS 작성에 팀원을 모두 참여, 프로젝트에 대한 이해도 향상 업무 연관관계 선/후 파악 시 활용 원가관리(Cost) Work Package 단위로 원가를 산정하고 감시 및 통제 시 활용 범위관리(Scope) 프로젝트 범위기획 단계에 상세한 프로젝트 범위기술서를 토대로 WBS를 작성함 승인된 프로젝트 범위기술서, WBS, WBS Dictionary는 프로젝트 범위 기준선으로 활용 일정관리(Time) WBS의 최하위 작업분류체계 구성요소에 포함된 계획된 작업이 작업패키지(Work Package) 활동 정의에서 작업분류체계의 작업패키지(Work Package)를 토대로 다시 일정활동이라고 하는 더 세부적인 구성요소로 분할되어서 프로젝트 작업에 대한 산정, 일정 수립, 실행, 감시 및 통제 프로세스의 기본을 제공 작업패키지 단위로 일정을 계획 시 활용 보통 2주 단위로 Work Package를 정의하지만, Agile을 적용하는 경우 빠른 반복 수행이 실시되므로 1-2일 단위로 Work Package가 정의 됨 방법론과 프로젝트의 성격에 따라서 Work Package의 규정치가 정의 품질관리(Quality) 프로젝트에 영향을 주는 Work Package에 대한 품질보증, 통제 인적자원관리 (Human Resource) 인적자원 기획단계에서 RAM(Responsibility Assignment Matrix) 정의시 상위수준 책임배정 매트릭스는 작업분류체계의 각 구성요소를 책임지는 프로젝트 팀이나 사업부를 정의시 활용 RAM은 수행해야 하는 작업과 프로젝트 팀원 사이의 연결을 보여주는데 활용 의사소통관리 (Communication) 의사소통 기획단계에 추가적인 인도물 작성 또는 노력이 요구되는 경우 그에 따라 프로젝트 WBS, 일정, 예산이 갱신 위험관리(Risk) 정성적 리스크분석 단계에서 리스크 범주 정의 WBS 또는 기타 유용한 범주별로 분류 시 활용 조달관리 (Procurement) WBS와 작업분류체계 사전 구성요소는 프로젝트 범위에 대한 구조화된 상세계획을 제공

나. WBS와 PMI 9개 활동 영역과의 관계도

- WBS는 프로젝트 전체 범위를 포함하고 있으므로 누락된 범위 존재 시 일정, 원가에 직접적인 리스크를 발생시키며, WBS를 투입물로 받는 모든 프로세스에 문제 발생

CPM(Critical Path Method) 네트워크 가. 정의
노드와 간선으로 구성된 네트워크
노드에는 작업을 표시하고 간선은 작업사이의 선후 의존관계를 나타냄
간선을 나타내는 화살표의 머리에 있는 작업은 화살표 꼬리에 있는 작업이 끝날 때까지는 시작할 수 없음
이정표 : 프로젝트의 중요한 중간 결과를 완성하였다는 표시 나. CPM의 장점
관리자의 일정 계획에 도움을 줌
프로젝트의 작업 사이의 관계 나타내며 최장경로를 파악이 가능
병행작업이 가능하도록 계획 및 자원 할당이 가능
다른 일정 계획안 시뮬레이션이 가능
프로젝트 일정을 점검하고 관리 가능
CPM의 이해 가. CPM 소작업 리스트

소작업 선행작업 소요기간(일) 가 없음 8 나 가 10 다 가 5 라 없음 3 마 없음 7 바 나 2 사 다, 라 1 아 마 6 자 바, 사, 아 4

나. CPM 네트워크와 임계경로(Critical Path)의 예 - 원형노드 : 소작업을 나타내는 것으로 작업 이름과 소요기간을 표시 - 임계경로(Critical Path) : 작업하는 시간이 가장 오래 걸리는 경로로 이 경로에 있는 작업 시간이 늘어나면 전체 작업시간이 늘어남 - ES(Earliest Start time) : 작업을 가장 빨리 시작할 수 있는 시간 - LS(Latest Start time) : 작업을 가장 늦게 시작할 수 있는 시간 - EF(Earliest Finish time) : 작업을 가장 빨리 끝낼 수 있는 시간 - LF(Latest Finish time) : 작업을 가장 늦게 끝낼 수 있는 시간 - Slack time(여유기간) : 작업을 하는데 가질 수 있는 여유 기간(LS-ES or LF-EF) => 임계경로(Critical Path) 구간은 여유 시간이 0, 즉 여유가 하나도 없는 구간

가능 경로 소요기간(일) 가->나->바->자 가->다->사->자 라->사->자 마->아->자 24 18 8 17

임계경로 : 가->나->바->자(24일)
프로젝트 매니저가 가장 신경을 써야 하는 구간
위 표에서는 CP가 1개 였지만, CP는 경우에 따라 여러개가 될 수 도 있음(최장기간이 동일한 구간이 여러개가 될 수 있음)
CP가 많아지게 되면 프로젝트의 위험(Risk)이 올라감
각 활동들의 수행 기간이 일부 변경되는 경우가 발생한다면 CP도 변경될 수 있음
예를들어 활동 “사”의 수행기간이 기존 1일에서 8일로 변경된다면 가->다->사->자 로 변경 됨 나. CPM 네트워크와 임계경로(Critical Path)의 Activity 순방향 분석 예
표기방법

다. CPM 네트워크와 임계경로(Critical Path)의 Activity 역방향 분석 예 - 표기 방법

라. 순방향 및 역방향 분석 예시 - 순방향 분석 : 왼쪽부터 오른쪽으로 계산하는 방식 - 역방향 분석 : 오른쪽부터 왼쪽으로 계산하는 방식

마. TF(Total Float), FF(Free Float) 분석 1) Total Float(TF) - Slack Time 이라고도 하며, 프로젝트 납기일을 지연시키지 않으면서 각 활동이 가질 수 있는 여유시간 - 공식: TF = Min {LS-ES, LF - EF}. 즉 LS-EF 와 LF-EF 값 중 작은 값 - CP(Critical Path) 구간은 TF가 0인 구간이다 - TF > 0 경우에는 일정에 여유가 있는 것이며 TF = 0은 일정 여유가 없는 CP(Critical Path, 임계경로) 구간 2) Free Float (FF) - 후행 활동의 착수일(ES)을 지연시키지 않으면서 선행(직전) 활동이 가질 수 있는 여유시간 - 공식: FF = EF - 후행 ES 3) TF, FF 표기 방법

4) TF, FF 계산 공식 도식화

3) TF, FF 분석 예시

조건) Activity 테이블

Activity 기간 선행 A 3 - B 7 A, D C 5 B D 6 - E 2 A, D F 1 B, E

가. 프로젝트 네트워크 다이어그램 작도 1) 각 Activity의 기간과 선행 Activity 정보를 바탕으로 선후 관계를 나타냄

2) Activity의 ES(early start), EF(early finish)를 나타냄 - 선행 작업 중 가장 늦게 끝나는 기간을 입력 받아서 더함

3) Backward Pass로 각 Activity의 LS(last start), LF(last finish)를 나타냄 - 프로젝트 종료일부터 계산 (즉 C의 18일부터 계산을 시작, F작업도 18일 종료 이기 때문에 18일부터 시작) - 오른쪽부터 왼쪽으로 기간을 뺀다 (F: 18-1=17, 즉 17일에 시작해도 18일에 종료 가능, C: 18-5=13) - 후행 작업 중 가장 빨리 시작하는 일자를 입력 받음 (즉 A는 후행 작업 B, E가 있지만 B의 작업이 E보다 빨리 시작하므로 A는 6일 입력 받음)

☞ 작업 E의 경우 빠르면 6일에 시작해서 2일을 작업하여 8일에 종료 하거나, 늦어도 15일에 시작해서 2일을 작업해서 17일까지 끝내면 된다는 의미 나. 여유시간(total float) 구하기 - 여유시간 : A : 6-3=3, B : 13-13=0, C : 18-18=0, D : 6-6=0, E : 17-8=9, F : 18-14=4 - Float(total float) = LS – ES = LF – EF에 의해 계산됨

여유시간(total float)은 프로젝트 완료일 지연에 영향을 주지 않고 활동이 가질 수 있는 여유시간 의미 다. Critical path 구하기
Critical path : D, B, C
Critical Path란 여유기간(total float)이 없는(0) 작업들의 경로

- Critical path 내의 작업이 지연되면, 프로젝트 전체 기간이 늘어나게 됨

Critical Chain과 Critical Path의 개념적 비교 가. Critical Chain의정의
프로젝트 Resource 측면에서 단순 Activity의 선후행이 아닌 투입 자원들의 연관관계를 통해 구성된 Activity 경로 나. Critical Path의정의
프로젝트의 전체 일정을 지연 시키지 않고 가질 수 있는 여유기간이 0인 Activity들로 연결된 경로(인력 측면의 자원 제약요소 발생 가능성 내포)
Critical Chain과 Critical Path의 상세 비교 가. 일반적 특징 비교

구분 Critical Chain Critical Path 착수일 Latest Start Date Earliest Start Date 관리 관점 전체 버퍼의 소진율 진철률, EVM 버퍼 버퍼를 모아서 관리 각 Activity에 버퍼 반영 자원 제약 자원 제약자체를 계획에 반영 Activity사이의 연관관계를 고려, 일정계획후 Resource Leveling을 통해 해결

Critical Chain은 프로젝트가 계획 단계에서 부터 자원의 가용성을 고려하므로 보다 현실적인 계획수립 가능(개발기간 단축효과) ※ EVM(Earned Value Managemenet)
작업의 진척을 양적으로 분석해내는 방법으로서 프로젝트 완료비율을 산정
범위, 일정 및 자원을 통합하고 프로젝트 성과 및 진행율 객관적으로 측정하는 관리 기법 나. 적용 예시를 통한 비교
PERT/CPM으로 구한 일정계획에 자원 평준화(resource leveling)를 수행한 후 새로 계산한 Critical Path는 Critical Chain과 같다
Critical Chain의 고려 필요사항 및 변경관리측면 중점사항 가. Critical Chain의 고려 필요사항
Activity 중심의 일정산정 및 실 투입 자원할당 기준에 의거한 실질적인 일정관리에 필요
Critical Chain의 조정은 프로젝트의 일정 지연 요소가될 수 있으므로, 조기관리 필요 나. Critical Chain 및 Path의 변경관리 측면 중점사항
일정 변경 요소 발생시 Critical Path측면의 일정 단축 방법을 최우선 고려
일정 지연처리 필요시에는 투입자원의 Status를 고려하여, Resource Leveling을 최소화할 수 있도록 조정 ※ 애로사슬관리(CCPM, Critical Chain Project Management) ※ 소프트웨어 개발 프로젝트의 작업 소요시간을 정할 때 사용하는 CPM(Critical Path Model : 임계경로방법)
CPM(Critical Path Method) 네트워크로 나타내었을 때, 임계경로(critical path) : start-A-C-E-end
임계경로는 프로젝트를 완료하기 위해서 액티비티 간 연결한 최장경로를 의미한다. 그래서 임계경로에 있는 액티비티가 완료되어야 프로젝트가 종료된다. ※ PERT[Program Evaluation and Review Technique]의 3점 산정기법(Three-Point Estimate) - 3점 산정기법 중 완료 기간 평균 산출 공식 M(Most Likely) : 확률적으로 가장 높은 값 O(Optimistic) : 가장 좋은 시나리오에 근거한 추정 값(확률적으로는 낮고, 기간 값은 최소) P(Pessimistic) : 가장 나쁜 시나리오에 근거한 추정 값(확률적으로는 낮고, 기간 값은 최대) 예) PERT의 가중평균치 방법을 이용할 경우, 어떤 활동의 수행 일정에대한 낙관적인 예측치는 2일, 가장 가능성이 높은 예측치는 5일, 비관적인 예측치는8일라고 할때 평균 예측치는? 따라서 (8+ 4*5 +2)/6 = 5

I. 일정수립도구 및 기법

관리기법 내용 Milestone - 프로젝트 일정상 발생하는 주요한 이벤트 중심 - 중간 목표가 달성되어야 최종목표 달성 - 이해 당사자, 경영층과 의사소통에 사용 Gantt Chart (Bar Chart) - 진척도 파악, 보고나 통제에 용이 - 프로젝트 시작 종료, 기간을 한눈에 파악 가능 - 액티비티 간의 연관관계 보여주지 않음 Network Diagram CPM - Critical Path(임계경로) Method. 1점 추정 - 내장된 여유시간을 가지고 있지 않은 일련의 업무와 작업 - 자원 제약을 고려하지 않고 각 작업들의 이론상 가장 빠른 시작일과 가장 늦은 종료일을 찾아 일정 관리 - 산정기간 변동 없는 한 예상 종료일 보다 빨리 끝낼 수 없음 PERT - Project Evaluation Review Technique - 3점 추정 방식으로 비관치, 낙관치, 실제 가능치 고려 공수산정 - 산정에 대한 경험 부족, 개인적 요소 보정 하고자 할 때 사용 - 액티비티 수행 기간 산정에 확률개념을 반영 - 평균공수 : T ={낙관치 +(4*실제 가능치)+비관치}/6 - 개별공수 표준편차 : S=(비관치-낙관치)/6

나. PERT와CPM 비교

다. 일정단축(Duration Compression) 1) 일정단축의 개요 - Scope의 변경 없이 프로젝트의 일정을 단축시키는 수학적 분석방법 2) Crashing(공정압축) 기법 - 자원(비용)을 Critical path상의 액티비티에 추가 투입하여 프로젝트 기간을 단축하는 기법 - Critical path중에서 비용대비 효과가 높은 액티비티에 우선적으로 투입 - 고객이 납기 단축을 요구하는 상황에서 Crashing은 비용초과를 유발하므로 반드시 고객의 승인이 필요함 3) Fast tracking(병렬처리) 기법 - 작업간 관계(logical relation)를 조정하여 병행 추진(Load를 찾아냄)하여 기간을 단축 - 재작업(rework)으로 인하여 기간이 늘어날 수 있는 위험(risk)을 내포 4) Resource Leveling(자원평준화) 기법 - 고급인력으로 교체, 잔업(Crashing과 동일한 효과), 아웃소싱, 범위축소, 품질희생 등이 방법이 있음 5) Crashing과 Fast tracking의 비교

구분 Crashing Fast Tracking 장점 유휴 리소스의 효율적 활용가능 프로젝트 일정의 Reserve 확보가능 제약사항 투입인력에 여유가 있는 Activity가 존재해야 함 CP상의 Activity에 적용불가 사례 인사시스템 개발시 발령모듈 개발자를 급여모듈 개발에 투입 시스템설계 시작과 함께 HW, SW 서버 동시설치 및 설정작업

※ 일정관리 방법론 간트차트(Gantt Chart) - 프로젝트 일정관리를 위한 바(bar)형태의 도구로서, 각 업무별로 일정의 시작과 끝을 그래픽으로 표시 - 과업을 독립적인 활동으로 간주하고 상호 연결된 속성을 미고려 - 작업 순서 흐름을 파악 - 작업의 병행 진행을 표현 - 인적자원 및 기타 자원의 할당에 사용

개발 실무자 관점에서의 개발 일정 준수 향상 방안 가. 개발 위험 요소의 사전 제거 방안
S/W 측면: 각 기능별 대응 가능 여부를 사전 선행 개발을 통해 개발 가능 여부를 파악함
H/W 측면: 각 Component 별 성능과 기능 위주 검증을 선행 나. 신규 사양에 대한 NUDD 적용 방안 ( 특정 기업에서 사용하고 있는 예 )
Project 개발 전에 NUDD Item 를 선정하고 선행 검증을 통해 Risk 없앰

측면 항목 4가지 항목 (NUDD)

설명 New : New function / Parts / Algorithms / Layout 이 포함되어 있는가? Unique : 고유기능과 차별화 기능이 있는가? Different : 모든 변경점, 기능 삭제 Difficult : 고 난이도 차별화 기능, 구현 기간이 길다.

개발 단계 Risk Factor 를 사전 발췌, 잠재 불량 검증 대책으로 활용
Risk 관리를 위한 Project 난이도를 사전 점검을 통해 Load 분석, Resource 할당 다. 과거 경험사례에 대한 적용
FMEA(Failure Mode Effect Analysis) : 실패에 대한 영향도 검토를 통한 회피 전략 구사
CLCA(Close Loop Corrective Action ) : 문제점 재발 방지 대책 및 향후 검증 방안 수립
Post Mortem : 각 Product 개발 완료 후 개발 과정 Review를 통해 수렴된 내용 적용
Check List : 각 업체별 요구사항에 대한 Check List 검증 자동화 라. 표준 Spec.의 변경점에 대한 관리
표준화 사양 : 국제 표준화 변경점 관리 및 Forum 참여
표준화 Spec. 제작 : 기술 선도 및 Royalty 확보

요구분석

요구분석 가. 분석 단계 : 현재의 상태를 파악하고 요구를 정의한 후, 문제 해결과 구현될 시스템의 목표를 명확히 도출 나. 명세서 작성 : 완성될 소프트웨어가 어떤기능을 가져야 하는가를 정확히 기술
소프트웨어 요구사항 분석 가. 문제 분석(analysis) : 사용자와의 인터뷰, 설문조사, 실사 등을 통하여 현황 등을 파악하고 새로운 시스템에 대한 요구를 찾아냄 나. 문제 정의(description) : 인식한 사항들에 대하여 올바른 기법과 관점을 검토 다. 프로타이핑과 시험 : 분석된 기능적 요구의 타당성을 시험하기 위한 프로토타입 개발 라. 문서화(documentation)와 검토(validation) : 요구 정의 및 명세화

요구사항 분석을 위한 페르소나의 개념 가) 페르소나의 정의
어떤 제품 혹은 서비스를 사용할 만한 목표 인구 집단안에 있는 다양한 사용자 유형들을 대표하는 가상의 인물
연결지향성 특징을 갖는 MPLS 기술을 이용하여 공용의 인터넷 상에서 가상의 VPN(IP-VPN)을 구성하는 기술 나) 페르소나의 특징 및 구성

특징 - 어떤 제품이나 혹은 서비스를 개발 하기 위해, 시장과 환경 그리고 사용자들을 이해하기 위해 사용 - 어떤 특정한 상황과 환경속에서 어떤 전형적인 인물이 어떻게 행동할 것인가에 대한 예측을 위해 실제 사용자자료를 바탕으로 개인의 개성을 부여하여 만들어짐 구성 가상의 인물을 묘사하고 그 인물의 배경과 환경등을 설명하는 문서로 꾸며지는데 가상의 이름, 목표, 평소에 느끼는 불편함, 그 인물이 가지는 필요 니즈등으로 구성

페르소나를 하는 이유

커뮤니케이션 - 프로젝트 관련자 (기획자, 개발자, 디자이너, 의사결정권자 등) 들이 사용자를 이해함에 있어 동일한 인식을 공유 - 유형화된 형태로 모두가 공통된 모습의 타겟 이용자를 생각하고 프로젝트를 진행 - 공유된 사용자 인식을 바탕으로 의사소통을 원활히 함 사용자 니즈 파악 - 타겟 포커싱이 수월해짐 - 사용자 그룹의 동기, 니즈, 다른 행동 패턴에 대한 정보를 제공함으로써 기획자/디자이너/프로그래머가 사용자 기반의 의사결정을 하는 데 기준이 됨 - 사용자에 대한 일치된 관점을 가지게 도와주며 프로젝트가 진행되고 규모가 커짐에 따라 자칫 흐려질 수 있거나 방향을 잃을 수 있는 사용자에 대한 관점을 유지할 수 있도록 도와줌 - 예상 사용자를 성별, 연령, 직업, 사회적 지위 등 다양한 분류로 나누고 sorting 디테일하게 파악할 수 있음

유저 리서치를 통해 얻은 데이터를 더욱 실제적이고 쓸모있는 것으로 만들고, 이를 통해 사용자의 특징이나 요구사항을 구체적으로 분석해 사용자에 대한 관점을 이해
페르소나를 하는 절차

가상화 기본이 되는 사항으로, 고객 설문이나 사용 후기의 양식을 통해 얻은 자료를통해 고객의 과거 경험을 파악하고 이를 통해 니즈를 분석하고 최종적으로 가상의 고객(메타포)을 설정하는 것 리서치 유저 리서치를 통해 얻은 정성, 정량 조사 자료를 기반으로 하여 만들어지는 것이기 때문에 신뢰성 있는 리서치가 진행 실체화 사실에 기반한 유저 리서치 자료를 통해 얻어진 것이기에 신뢰할 수 있는 데이터임을 늘 인지 다양한 요구사항 최대한 다양한 요구사항을 고려하여 한 제품/서비스에 대해 하나 이상의 페르소나가 존재한다는 사실을 충분히 인지 재구성 페르소나로 재구성 하는 과정에서 조사자 임의에 맞게 자료를 재구성하는 일이 없도록 주의하여 마지막까지 오염되지 않은 페르소나를 뽑아내는 것이 중요

페르소나의 사용
기업들은 사용자 경험 측면에서 차이를 기준으로 하는 것이 아니라 구매하는 제품에 따라 고객들을 세분화
페르소나 과정은 기업들이 고객을 바라보는 새로운 방식을 제안

프로젝트 성공을 위한 요구사항 명세 개요 가. 요구사항 명세서의 개념
프로젝트 참여자들 사이에 의사소통의 수단을 제공하며 자연어, 정형언어, 그래픽 형태 기술 언어로 요구사항의 일치성과 상호참조를 위해 작성된 명세서 ※ 소프트웨어 요구사항 명세(Software Requirement Specification, SRS) ※ 요구사항 명세서 지녀야 할 기본 조건
설계 과정을 위한 문제의 정의에 도움을 줄 수 있을 것
소프트웨어가 올바르다고 판단하기 위한 수단으로 사용할 수 있을 것
소프트웨어 제품 및 개발과정을 공학화하는 핵심이 될 수 있을 것 나. 요구사항 명세의 목표
고객과 개발자 사이에 공통의 이해를 위한 Baseline 제공

다. 요구사항 명세서의 목적 - 참여자들 사이의 의사소통, 요구사항의 추적성, 변경의 통제성, 요구사항의 반영 준수 - 요구사항 명세서의 관점별 목적

관점 요구사항 명세서의 목적 사용자/고객 프로젝트에 대한 요구사항 정의, 정의된 요구사항의 적용 및 추적성 최종 산출물 및 SW에 대한 의사소통 채널 프로젝트 품질 및 납기(검수)의 기준 개발자 SW목적물의 설계에 맞는 개발 진행 사용자/고객의 의사소통 창구(요구사항 반영) 테스트 및 검수 결과의 기준 설계자 설계된 목적물의 기준(기능과 제약조건) 설계 중요도 및 우선순위 배정의 기준 관리자(PM) 프로젝트 품질 관리 기준(요구사항관리, 요구사항추적, 테스트, 품질관리) 프로젝트 범위(Scope)에 대한 기준(수용여부)

※ 의사소통 채널의 수를 계산하는 공식은 n(n-1)/2 이다. - 팀원이 5명인 경우의 의사소통 라인 수는 5(5-1)/2 = 10 - 팀원이 10명인 경우의 의사소통 라인 수는 10(10-1)/2 = 4 라. 요구사항 명세의 전략

마. 요구사항 명세서의 명세 기준

기준 설명 간결성 요구사항 명세서는 이해하기 쉽고, 간결하게 작성 제약조건 요구사항 명세서의 정의된 내용은 시스템의 제약조건을 명확하게 선정 검증성 정의된 요구사항이 검증될 수 있도록 명시 우선순위 요구사항에 대한 중요도를 부여하여 우선순위를 산정 시스템 별 명세기법 시스템에 따라 명세기법을 적용 • 데이터 집약적 : ERD(개체 관계도) • 입력에 대한 처리 : 상태전이도, 상태차트 • 판단이 중요한 시스템 : Decision Table ※ 상태전이도(STD, State Transition Diagram) ※ 요구사항 정의 및 분석단계 현재의 물리시스템과 논리시스템의 상태 파악 개발할 시스템이 갖추어야 할 전반적이고 주된 요구조건 정의 새로운 물리시스템과 논리시스템의 목표를 도출 보안, 백업요구 정의 ※ 기능요구 시스템이 제공해야 하는 서비스들을 기술하는 것. 시스템이 특정 입력에 어떻게 반응하는지와 시스템이 특정 상황에서 어떻게 행동하는지를 기술한다. - 입력 양식과 출력 보고서 정의, 키보드의 구체적인 조작, 명령어 수행 후의 결과, 한글/한자 관련 요구, 칼라/흑백 요구, 주기적인 출력자료에 관한 요구 ※ 비기능요구 - 사용자에 의하여 제기된 요구나 제안 중에 시스템의 기능과 관련되지 않는 사항 - 사용자가 특별히 원하는 사항이나 특성, 품질에 대한 요구, 시스템에 대한 제약사항 - 시스템의 성능을 나타내는 처리량, 응답시간, 보안성, 신뢰성, 오류 처리 및 제약 조건, 품질, 자원관리대책, 개발비용 ※ warnier-orr 자료구조 중심 설계 방법 : DSSD(Data Structured System Development)개발 방법론이라고도 하며 자료구조를 통해 소프트웨어 구조를 유도할 수 있다고 본다. 순차, 선택, 반복의 세 가지 구조를 사용해서 정보계층을 표현하기 위한 표기법이다. 출력 자료구조로부터 프로그램 구조와 입력 자료구조를 추론한다. ※ jackson 자료구조 중심 설계 방법, 입출력 데이터 구조로부터 프로그램 구조도를 유도해낸다 ※ 자료 흐름 중심 설계 방법 : DeMarco, Yourdon, Constantine ※ 구조적 분석방법 : 자료사전(DD), 개체 관계도(ERD), 데이터 객체기술(DOD Data Object Description), 데이터 흐름도(DFD Data Flow Diagram) 프로세스 명세(Process specification), 상태전이도(STD State Transition Diagram), 제어명세(CSPEC, Control SPECification), 흐름도, NS도표 ※ DFD(데이터 흐름도)의 구성요소 : 프로세스, 자료흐름, 자료 저장소, 단말 ※ 미니명세서 표현 도구 - Structured English(구조적 문장, 구조적 영어)<-구조화된 자연어 방법 - 프로그램 설계 언어(PDL : Program Design Language), 의사코드(Pseudo code) - 의사 결정도(의사 결정 트리, decision tree) : 의사 결정하는 논리를 도형화 - 의사 결정표(decision table) : 조건과 이에 따르는 행동을 의사결정 규범으로 상세히 나열하는 것 - 실시간 소프트웨어 개발시 : 상태 전이도, 상태전이표 - 구조적 프로그래밍 설계 시 : NS-chart, 흐름도(flow chart) ※ 요구분석명세 - 구현방법이 아니라 필요한 기능성을 표시하는 것 - 소프트웨어의 컴포넌트들에 관한 정보가 포함 - 동작할 시스템 환경에 대한 정보가 포함 - 임의로 선정된 테스트 데이터에 대한 작동 가능성 확인 ※ 요구사항 명세화의 원리 - 요구되는 기능의 명세화는 구현과 독립 - 절차지향적인 명세화 언어가 필요 - 소프트웨어, 정보처리시스템의 전체 영역, 이용 환경을 전반적으로 명세화 - 각 요구명세는 개념적 모형이며 운용 가능 - 불완전성을 수렴 - 요구 명세는 부분적 정의이며 타 요구들과는 느슨(loose)하게 연결 2. 요구사항 명세의 조건 및 5가지 프로세스 가. 요구사항 명세의 조건

관점 조건 내용 비즈니스 관점 (발주자) 연결성 비즈니스 요구의 가시성 확보 수/발주간의 공통 기대/목적 제공 고객 관점 (감리자) 정량성 SW품질 향상 및 신뢰성 확보 고객 만족의 기준 제공 개발관점 (개발자) 정형성 개발의 정확성 제공, SW변경 최소화 발주자와 수주자의 의사소통 제공

SMART 요구사항 (Mannion & Keepence, 1995) Specific 명확한 표현, 일관된 용어, 간결한 표현, 적정한 상세 표현 Measurable 요구사항 만족 검증을 위한 방법, 기준 Attainable 기술적 타당성 Realizable 자원, 인원, 기술에 대한 현실성 Traceable Conception-Specification-Design-Implementation-Test

나. 요구사항의 5가지 프로세스

요구사항 관리 원칙 및 고려사항

관리원칙 고려사항 정확한 시스템 목표 식별 기대관리(Expectation Management) 범위관리(Scope Management) 고객중심 요구사항 관리 광범위한 사용자 참여 다양한 고객의 목소리 고객가치 중심의 요구사항 관리 고객가치 기반의 우선순위 부여 참여자 사이에 요구사항에 대한 동의 획득 지속적이고 점진적인 요구사항 관리 변경에 대한 추적을 통한 영향 분석 변경 단계별 요구사항 베이스라인 설정 요구사항 관리 조직문화 요구사항 관리에 대한 동기부여 및 지원 요구사항의 책임 조직의 요구관리 프로세스 제시 4. 요구사항 명세에 포함될 내용 및 제외될 내용 가. 요구사항 명세에 포함될 내용 및 제외될 내용

구분 항목 설명 포함될 내용 기능 구축될 소프트웨어의 기능 인터페이스 시스템과 연계되는 인터페이스 요구사항 성능 시스템에 요구되는 성능 요구사항 속성 이식성, 정확성, 유지성, 보안성 등 제외될 내용 프로젝트 요구사항 인원, 일정, 비용, 마일스톤, 단계, 보고 등 프로덕트 보증 요구 형상관리, 검증, 테스트 등의 계획 나. 비 기능 요구사항의 분류 및 제외대상

기준 설명 분류 프로덕트 요구사항 시스템이 가져야하는 특성, 사용 기능성, 성능 및 용량 요구사항(사용기능성, 신뢰성, 안정성, 효율성, 성능, 용량) 프로세스 요구사항 인수, 실행, 표준 요구사항 외부 요구사항 규정, 경제성, 상호운영성 검증 성능/신뢰성/유지보수 성능 : BMT 신뢰성 : MTTR, POFOD 유지보수성 : 가이드라인 지침 - 프로젝트 요구사항과 프로덕트 보증요구는 요구사항 명세서에서 제외 5. 요구사항 명세서의 목차 및 명세기법 가. 요구사항 명세서의 목차

목차 주요내용 1. 소개 목적, 범위, 정의, 참조, 개요 2. 전체 요구사항 2.1 프로덕트 관점 2.2 프로덕트 기능 2.3 사용자 특성 2.4 제약사항 3. 특정 요구사항 3.1 외부 인터페이스 요구사항(사용자, H/W, SW, 커뮤니케이션 인터페이스) 3.2 기능적 요구사항 3.3 성능 요구사항 3.4 설계 제약사항 3.5 기타 요구사항 3.6 SW 시스템 특성

나. 요구사항 명세 기법

분류 주요내용 정형명세 수학적 기반의 기술 명세개발 및 체계적 시스템, 검증 프레임워크 제공 모델링 기반 언어 Z명세 기법, VDM(Vienna Development Method) 대수처리 기반 언어 CSP, CCS 비정형명세 상태중심 FSM(Finite State Machine) 기능중심 Decision Table, ER 모델링 객체중심 State chart(SADT)

나. 요구사항 명세 속성

명세 속성 주요내용 정확성 명확화된 요구사항이 실제 시스템 구현시 필요한 것인지 알 수 있도록 정확해야함 명확성 여러가지가 아니라 단 한지로 해석되어야 함 완전성 시스템 구현에 필요한 모든 것이 표현되어야 함 일관성 요구사항들 간의 충돌이 없어야 함 수정용이성 구조와 스타일에 일관성을 유지하면서 요구사항 변경이 용이해야 함 추적성 요구사항들 간에 유기적으로 연결되어 있어야 함

엄격하고 치밀한 요구사항 명세를 위한 요구사항 정형명세의 개념 가. 요구사항 정형명세의 개념
요구사항의 어휘, 구문, 의미가 수학적 개념(집합론, 논리와 대수 분야)에 의거 정형적으로 표현된 명세 나. 정형명세의 유형

유형 설명 대수하적 방법 오퍼레이션과 이들 사이의 관계로 시스템을 표현 시스템을 분할된 서브 시스템간의 인터페이스로 간주 Larch, OBJ, Lotos 모형기반 방법 시스템을 상태모형으로 인식, 집합과 수열 등 수학적 요소로 표현 시스템에 있는 오퍼레이션들이 시스템의 상태를 어떻게 변화 시키는지에 초점 Z, VDM, CSP, Petri-Net

모형기반 정형명세 Z 정형명세 가. Z(제드) 정형명세의 특징
시스템의 자료구조와 상태 및 상태변환 연산을 구문적으로 구분하지 않고 스키마를 이용하여 동일하게 표현
명세의 기본작성 단위는 스키마 : 스키마 단위로 명세를 분할하여 작성하므로 시스템의 구조적 개발 지원
스키마는 상태변수를 소개하고, 그 상태에서 제약과 연산을 정의
명세는 정형명세와 함께 비정형 기술을 허용
각 스키마의 세분화가 가능하므로, 작성된 명세의 세분화가 가능, 세분화의 결과로 명세간의 일치성 검증용이 및 스키마의 재사용성 높음
명세의 도식적인 표현으로 시스템 개발 참여자가 작성된 명세 이해용이
스키마는 스키마 합성, 스키마 재명명, 스키마 은닉과 같은 연산을 사용하여 조작 가능
명세안의 상태와 연산의 구문적인 구별이 없어서, 각 스키마들간 존재하는 관계를 파악하기 위하여 전 명세를 검토해야 하며, 고급언어로의 변환과정이 복잡 나. Z 정형명세의 스키마의 구조
스키마 시그니쳐 : 시스템의 상태를 구성하는 개체를 정의
스키마 술어 : 그러한 개체에 대해 언제나 참인 조건을 지정(불변 조건 : invariant)
스키마가 연산을 정의할 때 술어는 사전조건(pre condition), 사후조건(post condition)을 지정
이러한 조건들은 연산전후의 상태를 정의
사전조건과 사후조건의 차이는 연산 스키마에서 지정된 행동을 정의
정형명세 기법의 특징과 제약사항
엄격하고 상세한 분석을 통해 프로그램의 오류를 줄여 SW의 품질을 향상
SW의 신속한 인도 및 적시성이 요구되는 SW에는 부적합
또한 정형기법은 사용자 인터페이스와 사용자 상호작용을 지정하는데는 적합하지 않음
정형 기법은 확장성이(시스템의 크기가 증가함에 따라 정형명세를 개발하기 위해 필요한 노력과 시간이 급격하게 증가) 떨어져서 비교적 규모가 작은 중요한 커널시스템 개발 프로젝트에 활용

정보시스템 요구공학의 개념 가. 요구공학의 개념
데이터 처리 문제를 해결하는 단계, 사용자 요구사항을 주의 깊게 인식하고 문서화
제품개발을 위한 요구사항 설정 단계부터 제품 개발과 테스트, 생산에 이르기까지 개발공정의 매 단계 마다 초기에 정한 개발 요구사항들은 물론 이후의 상세 요구사항들이 제품설계와 구현단계에서 제대로 지켜지고 있는지를 검증해 나가는 기법
시스템 요구사항 문서를 생성하고 검증하고 관리하기 위하여 수행되는 구조화된 활동의 집합으로 시스템적 해결이 필요한 문제에 대하여 관련 요구의 추출과 분석 및 문제를 해결할 수 있는 시스템의 외부행위를 기술하는 것을 포함하여 요구사항 명세를 최종 산출물로 생성(요구정의 활동)
요구공학 : 요구수집, 요구분석, 요구명세, 검증 등으로 구성 나. 요구공학 프로세스

1) 타당성 조사 : 요구공학과 시스템 개발 프로세스를 진행하는 것이 가치 있는 것인지 조사 2) 요구사항 추출 및 분석 : 응용 도메인에 대한 정보, 시스템의 성능, 시스템이 제공하는 서비스가 무엇인지 추출 및 분석, 요구사항 발견->요구사항 분류와 구성-> 요구사항 우선순위 설정과 협상->요구사항 문서화 3) 요구사항 검증 : 요구사항이 실제로 고객이 원하는 바를 정의했는지 검증, 유효성 점검, 일관성 점검, 완전성 점검, 실현성 점검, 증명가능성 점검 - 기법 : 요구사항 검토(증명 가능성, 이해용이성, 추적 가능성, 적응 가능성), 프로토타이핑, 시험사례 생성 4) 요구사항 관리 : 시스템 요구사항에 대한 변경을 이해하고 제어하는 프로세스, 각 요구사항을 추적하고 요구사항 간의 관계를 유지하여 요구사항 변경의 영향을 평가 - 요구사항관리 계획수립 : 요구사항 식별, 변경관리 프로세스, 추적관리 정책, CASE도구 지원 계획수립 - 요구사항 변경관리 : 문제분석과 변경 명세화, 변경분석과 비용산정, 변경구현 마. 요구공학의 어려움 1) 문제의 복잡성 : 시스템 개발 중 완전한 이해 및 엄밀한 기술 불가 2) 적용분야의 이해 필요 3) 오해발생 : 잘못된 의사소통 4) 요구사항의 불완전성(Incomplete), 모순(Inconsistent) 5) 요구사항은 항상 변함 2. 요구자료 수집기법 가. 요구자료 수집기법 - 정보시스템 분석을 위한 자료 수집, 사용자의 요구사항을 정확히 규명하고 업무처리 절차를 정확히 분석하기 위해서 사용자와의 주기적인 접촉과 함께 수집할 정보가 존재하는 위치, 용도, 중요성 등을 고려한 적절한 조사자료 수집기법 선택해야함 나. 요구자료 수집기법 별 특징 비교

구분 면담법 설문지법 문서분석법 관찰법 JAD법 조직의 주된 목적 현행 시스템 이해 및 개선 현행 시스템 이해 및 개선 현행 시스템 이해 현행 시스템 이해 현행 시스템 이해 및 개선 성패요인 면담설계 대화술 설문지 설계 조사자 개인의 능력 관찰력 세션설계 진행자의 자질 담당자의 협조 적절한 표본 이용 가능한 문서의 수 관찰시간 참여자의 선택 조사자의 능력 설문지 회수율 응답 분석력 정보의 원천 응답자의 지식 담당자 머리 문서, 업무양식 현장업무 참여자의 지식 소요시간 보통 보통 짧음 많음 많음 수집정보량 소량 소량 대량 대량 대량 정보의 폭 좁음 넓음 넓음 좁음 중간 정보의 깊이 깊음 중간 얕음 얕음 깊음 정보의 통합정도 낮음 낮음 낮음 낮음 높음 정보의 신선도 최신 최신 과거 현재 최신 정보의 신뢰도 보통 보통 높음 높음 높음 사용자 참여정도 높음 중간 낮음 낮음 매우 높음 비용 중간 낮음 낮음 높음 높음

요구자료 수집기법의 장∙단점 비교

기법 장점 단점 면담법 사용자의 요구를 심도 있게 파악가능 주관적, 편견된 정보일수 있음 질∙양적 정보 모두 획득가능 다른 방법을 통한 정보의 정확성 검증 필요 상세정보 및 요약정보 획득가능 면담자의 수가 많을수록 부적절함 설문지법 많은 사람들을 대상으로 조사가능 무응답이 생길 수 있음 응답자의 익명성 보장가능 질문항목의 신뢰성과 타당성이 검증되어야함 응답자의 태도나 감정을 정확히 표현 응답자의 오류에 대한 통제 불가능 폐쇄식 질문을 통한 객관적인 정보의 취득가능 문서 분석법 객관적 자료의 이용가능 현재의 사용 문서가 미래에도 지속되어 업무 개선 효과 저해가능 문서를 얻기가 용이함 사용자의 태도나 동기 등에 대한 정보파악이 어려움 문제영역의 현상파악 용이함 관찰법 말로 표현하기 힘든 내용 이해 관찰시 작업자의 행동에 영향 미침 편견과 주관성 배제가능 모든 상황 관찰이 어려움 문제영역에 대한 이해용이 많은 시간을 요함 JAD기법 다양한 정보의 취득과 분석가능 회의참석자가 많을 경우 의사 결정을 내리는데 많은 시간이 필요함 합리적 의사결정을 통한 합일점 도달 논쟁으로 많은 시간을 보냄 사용자의 요구사항을 정확히 파악 회의진행을 위한 전문가 확보가 어려움 많은 사용자 참여를 통한 요구분석과 이해도 증진 특정인물에 대한 회의주도 및 의견 획일화 우려 존재 전문 진행자에 의한 회의진행

요구사항 수집 및 사용자와의 대화 방법, 인터뷰 가. 인터뷰(Interview)의 개념
개발 될 시스템과 관계된 조직의 직원 및 분야의 전문가와 직접 대화하여 요구되는 정보를 뽑아내는 방법
시스템이 담당할 업무의 내용과 이에 필요한 다양한 문서 및 데이터를 수집하는 기법 나. 인터뷰 효과 극대화 원칙

원칙 설명 3대 7원칙 30%는 인터뷰어, 70%는 인터뷰 대상자가 말하도록 한다 1.5HR 원칙 인터뷰 시간은 1시간 30분을 넘기지 않는다 2인 이상 참여 원칙 1:1 보다는 2인 이상 참여하여 주제별로 번갈아 가며 수행한다

인터뷰 질문 유형과 전개 방법 가. 인터뷰 질문 유형

질문유형 설명 장•단점 열린 질문 (Open questions) 인터뷰 대상자가 의사를 자유롭게 답변할 수 있도록 하는 유형 예) “~에 관한 의견을 말씀해 주십시오” 장점 : 자유롭게 많은 정보 획득 단점 : 주제를 벗어날 수 있음 닫힌 질문 (Closed questions) 구체적인 질문을 통해 인터뷰 대상자가 답변할 범위를 제한하는 유형 예) “~를 하루에 몇 건 수행 하십니까?” 장점 : 목적에 맞는 정보 획득 단점 : 추가정보 획득 어려움 추가 질문 (Follow-up questions) - 바로 앞 질문의 답변에 대해 명확히 또는 구체적으로 알고자 할 때 수행 - 필요할 경우에 수행

나. 질문 전개 방법

1) 피라미드 구조(pyramid structure) 2) 깔때기 구조(funnel structure)

구체적인 닫힌 질문부터 일반적 열린 질문으로 전개
응답자가 아이디어가 떠오를 수 있도록 하거나, 주제에 대하여 답변을 꺼릴 때 적용
열린 질문부터 점차 닫힌 질문으로 전개
현황 파악을 목적으로 초기에 실시하는 일반 인터뷰 실시에서 주로 사용

3) 다이아몬드 구조(diamond structure) - 구체적인 닫힌 질문 > 일반적인 열린 질문 > 다시 구체적인 닫힌 질문 - 닫힌 질문으로 인터뷰를 시작하고, 추가 요구사항 도출을 위해 열린 질문으로 전개, 열린 질문에 대한 응답내용을 명확히 하기 위해 추가 질문을 닫힌 질문유형 하면서 인터뷰를 마무리 - 장점 : 다양한 질문을 통해 응답자의 주의와 흥미를 유도 - 단점 : 상대적으로 시간이 많이 소요 됨 3. 인터뷰 수행 시 주의사항 1) 답변을 유도하거나 응답자를 속박하지 않도록 주의

나쁜 예 좋은 예 “대다수 팀원들이 생각하는 것처럼 업무 프로세스가 개선되어야 한다고 생각하나요?” “업무 프로세스 개선에 대해 어떻게 생각하나요?”

2) 인터뷰 대상자의 반응에 적절히 대응 - 주제를 벗어나는 경우 : 원래 준비한 인터뷰 질문내용으로 유도 - 불평하는 경우 : 경청만 함 - 화를 내는 경우 : 관심을 다른 방향으로 유도

요구사항의 누락방지 및 변경영향 분석을 위한 요구사항 관리의 기본, 요구사항 추적성 가. 요구사항 추적성 정의
합의된 요구사항 ID가 부여된 요구사항이 구현되기 위해 필요한 컴포넌트간 대응관계를 파악해 주는 품질속성 나. 요구공학에서의 요구사항 추적성의 목적

V모델에서의 요구사항 추적성 요구사항 추적 매트릭스에서의 추적성 수평 추적성 (요구사항-테스트연계 추적)

수직 추적성(단계별 산출물간 대응관계 파악) 전방향 추적성 (요구사항-산출물 연계 추적)

후방향 추적성 (이전 단계의 산출물 추적 및 변경영향 분석물 연계 추적) Verfication & Validation 원칙에 입각하여 SDLC 단계별 산출물간 연계성 파악 및 각 산출물에 대한 테스트 케이스등의 테스트 방안 수립 특정 요구사항에 대한 가시성 확보 및 산출물간 대응관계 파악, 이전 단계 산출물 추적, 변경영향 분석등의 요구사항 추적을 위한 기본적인 도구

요구사항 추적성을 확보하기 위한 방안

구분 세부방안 설명 요구사항 수립단계 RFP 및 계약서 추상적이지 않고 명확한 요구사항 및 이해관계자가 합의한 계약서 SOW 및 WBS 사용자와 개발자가 합의한 구현해야하는 요구사항에 대한 명확화 요구사항 정의서 기능/비기능 요구사항에 대한 체계적인 분류 및 구조화 프로젝트 진행단계 요구사항 추적 매트릭스 요구ID, 컴포넌트ID, 테이블ID, 테스트 케이스ID 등의 대응관계 추적 변경영향 분석(CCB) 특정 모듈 변경시 예상되는 변경모듈 파악 및 CCB 통한 승인

ALM 및 CI 도구 변경 발생시 회귀테스트 및 테스트 자동화를 위한 개발 도구

체계적인 요구사항 추적 및 관리를 위한 방안

구분 설명 명확한 요구사항 식별 구현해야할것과 구현하고싶은 것은 다른것임. 비기능 요구사항에 대한 정량화 요구사항 추적 관리 요구사항 추적표, 추적매트릭스를 활용하여 산출물간 대응관계 및 누락 방지 자동화 도구 사용 자동화된 추적표, 변경영향 분석을 통한 변경모듈 구현 및 회귀 테스트 수행

요구분석방법

요구분석방법 가. 구조적 분석, 객체지향 분석, 정보공학 방법, 정형화 방법 나. 구조적 분석(structured analysis)
전통적인 데이터 처리 시스템을 개발하는데 많이 쓰이는 적절한 기법
시스템을 구성하는 프로세스들 사이의 데이터 흐름을 파악
프로세스 데이터를 생성하고 다른 형태로 변환하여 출력
시스템을 기능적 관점에서 다룸(데이터 보다는 처리 즉 기능을 위주로 분석하는 방법)
프로세스와 프로세스들 사이의 자료 흐름으로 추상화하는 방법
모델 : 자료 흐름도, 자료사전, 소단위 명세서
자료흐름도 => 시스템 안의 프로세스, 자료 저장소들 사이에 자료의 흐름을 나타낸 그래프
자료사전 => 자료 흐름도에서 사용된 모든 자료 요소가 표현
소단위 명세서 => 자료 흐름도의 프로세스에 대한 자세한 작업 과정이 기술
작업순서 => 배경도 작성 => 상위 자료 흐름도 작성 => 하위 자료 흐름도 작성 => 자료사전 작성 => 소단위 명세서 작성 다. 객체지향 분석
문제 도메인을 쉽게 설계할 수 있고 쉽게 이해할 수 있음
요구가 변하더라도 시스템의 기본 구성단위인 객체는 면역성이 있어 변화에 쉽게 대처
실세계의 개념과 객체가 밀접하게 연관되어 있고 상속이라는 개념으로 재사용이 용이
새로운 시스템을 개발할 때 현존하는 모듈을 효과적으로 사용함으로써 개발 비용과 시간을 절약
요구를 추출하고 이를 사용 사례로 표현
사용 사례 : 시스템이 수행할 것으로 기대되는 기능, 사용자 또는 외부 시스템이나 기타 요소들이 시스템과 상호작용 하는 다이얼로그를 모델링
액터 : 시스템과 인터랙션 하는 엔티티

자료 흐름도 구성요소(DFD, Data Flow Diagram)
자료 흐름도 작성 예 가. 자료 흐름도 예

나. 식빵 공장 자료 흐름도

다. 식빵 만들기 자료 흐름도

자료 흐름의 균형
상위 단계의 어떤 프로세스에 대한 입력과 출력 자료 흐름은 분할된 하위 단계의 자료 흐름도에 입출력이 되어야 함
F라는 자료 흐름이 B와 C로 구성되어 있으면 자료의 균형 원칙에 위배되지 않음 그러므로 F라는 흐름이 B와 C로 구성된다는 사실이 명시되어야 함

자료사전(DD, Data Dictionary)
자료 흐름도의 자료 항목에 대한 정의를 모은것
자료사전 연산자 종류

+ 자료 요소가 다른 요소와 연결되는 것을 의미 | or의 의미 ‘ ’ 문자형 상수를 의미 [ ] 하나 또는 그 이상의 선택형 요소를 나타낼때 사용 { } 중괄호 안의 요소가 반복되는 것을 나타냄 { } 중괄호 안의 요소가 x번 이상 반복됨을 나타냄 { } 중괄호 안의 요소가 y번 이하 반복됨을 나타냄 { } 중괄호 안의 요소가 x번 이상 y번 이하 반복됨을 나타냄

자료사전 사용 예

구독자_전화_번호 = [지역_번호] + 국번 + ‘-’ + 가입자_번호 지역_번호 = ‘(’ + ‘0’ + 첫 자리 + {십진수} + ‘)’ 국번 = {십진수} 가입자_번호 = {십진수} 첫 자리 = 2|3|4|5|6 십진수 = 0|1|2|3|4|5|7|8|9

구독자_전화_번호를 진한 글꼴로 강조한 이유는 자료 흐름도에 나타나는 자료요소
지역_번호 자료요소는 생략될 수 있음을 나타냄
국번 자료요소는 2자리나 3자리의 십진수
가입자_번호 자료요소는 항상 4자리의 십진수

소단위 명세서
자료 흐름도의 최하위 프로세스가 어떤기능을 하는가를 기술
소단위 명세서(mini specification)=프로세스 명세서(process specification)=소작업 명세서(activity specification)
방법 : 구조적 영어(structured english), 의사 결정표(decision table), 의사결정트리, 나씨-슈나이더만(nassi-shneiderman) 도표, 전후 조건(pre/post condition)
구조적 영어
연산자 : Compute, Add, Get, Put, Find, Move, Replace, Set, Sort
순차적 구조

Compute Total-Sales Compute Sales-Tax Add Sales-Tax to Total-Sales to Compute Total-Bill

=> 한 가지 작업이 한 줄에 쓰이며 다음 줄에 쓰인 작업은 그 다음에 순차적으로 수행됨을 의미 - 선택 구조 => IF ~ THEN 문장

IF Condition THEN action END-IF

=> IF ~ THEN ~ ELSE 문장

IF Condition THEN action1 ELSE action2 END-IF

=> CASE 문장

CASE selector OF condition1 : action1 condition2 : action2 condition3 : action3 END-CASE

반복구조 => WHILE ~ DO

WHILE condition DO action END-WHILE

=> REPEAT ~ UNTIL

REPEAT action UNTIL condition

사용 사례 다이어그램(use case diagram)
시스템의 기능을 나타내기 위하여 사용자의 요구를 추출하고 분석하는데 사용
외부에서 보는 시스템의 동작에 초점
사용 사례(use case)와 액터(actor)로 구성
액터 : 시스템 범위 밖에 존재, 시스템과 상호 작용하는 외부 엔티티
사용 사례 : 시스템 안에 존재, 외부 동작(external behavior)
사용 사례 작업 순서 가. 액터 찾기
시스템과 작용하는 외부 엔티티
액터는 사람이 될 수도 있고 외부 시스템이 될 수도 있음 나. 사용 사례 찾기
소프트웨어를 사용할 업무나 조직의 프로세스를 기술하는데 사용
시스템의 어떤기능을 수행할 때 정상적인 흐름만이 아니라 오류, 예외 케이스도 포함 다. 사용 사례 관계 찾기
포함관계(include) : 사용 사례 중복을 줄임

=> 점선 화살표로 표시하고 화살표 위에 <> 표시 => Rent Video와 Return Video는 바코드 스캔하여 비디오 정보를 데이터베이스에서 찾는 Get Video ID라는 사용 사례 포함 - 확장관계(extend) : 정상적인 이벤트와 예외적인 이벤트를 분리

=> 점선 화살표로 표시하고 화살표 위에 <> 표시 => Edit Customer Profile이라는 사용 사례는 미성년자를 위하여 부모 허락을 받는 사용 사례 Parental Authorization으로 확장 => 결국 Parental Authorization 사용 사례가 Edit Customer Profile의 확장

설계 원리와 아키텍처

소프트웨어 설계
소프트웨어를 이루는 모듈들을 정의하고 모듈 사이의 인터페이스를 기술하는 것을 의미
산출물 : 시스템 구조도와 모듈의 상세한 알고리즘, 자료에 대한 설계가 포함된 설계서
시스템 구조도 : 소프트웨어를 구성하는 모듈을 정의하고 모듈 사이의 관계를 나타내는 문서
아키텍처 설계 : 전체 시스템을 이루는 서브시스템, 또는 모듈이 무엇이며 서브시스템 사이의 관계를 파악하는 작업
인터페이스 설계 : 서브시스템 사이의 인터페이스를 설계하고 정의하는 작업
모듈 설계 : 시스템의 컴포넌트 되는 모듈, 즉 프로그램의 알고리즘에 대한 설계 작업
자료저장소 설계 : 파일이나 데이터베이스를 설계하는 작업
사용자 인터페이스 설계 : 메뉴나 입력 양식, 출력 화면 및 인쇄물을 설계하는 작업
설계의 원리 및 소프트웨어 설계의 원리 가. 설계의 원리

원리 설명 단순성 복잡한 여러가지 요소를 교통정리 하여 단순화 하거나 복잡함을 최소화 효율성 사용하는 자원이 적정하고 효과적 분할, 계층화 다루기 쉬운 덩어리로 분리하여 계층화 추상화 자세한 부분에 좌우되지 않게 컴포넌트를 정의 모듈화 각 모듈이 외부와의 결합이 낮고 내부요소가 응집되도록 설계

나. 소프트웨어 설계의 원리

원리 설명 추상화(abstraction) 처음부터 자세한 것을 다루지 않고 추상화하여 생각하고 점차 구체화하는 개념 정보 은닉 (information hiding) 한 함수 안에 특정 기능을 수행하는데 필요한 자료만을 사용 가능하도록 규제하는 원리 즉, 필요 없는 자료를 접근할 필요가 없는 개념 단계적 분해 (stepwise refinement) 처음부터 자세한 사항을 다루지 않고 단계적으로 분할하여 구체화 시키는 방법 모듈화 (modularization) 프로그램을 작고 독립적인 단위로 분할하는 기준 즉, 모듈의 내부 응집력을 크게 하고 다른 모듈과의 결합도는 작게함

추상화

구분 내용 예제 기능 추상화(function abstraction) 함수와 같은 서브프로그램 print() 클래스 내 메서드 정의 Obj.getName() 자료 추상화(data abstraction) 추상 자료형 정의 int, float 제어 추상화(control abstraction) 제어행위에 대한 개념화, 명령과 이벤트 if, for, while

가. 개념도

나. 기능 추상화 - 모듈이 수행하는 기능 측면으로 간략화 하는 방법 - 절차 중심의 접근 방법에서 분할하는 기준 - 문제를 분할할 때 시스템의 전체 기능을 구성하는 작은 기능들로 나눔 - 예 : 로그값을 계산하는 모듈은 계산하는 자세한 과정이나 알고리즘은 생략하고 함수 로그라는 이름으로 축약 다. 자료 추상화 - 자료 객체 밖에서는 내부의 내용은 가려져 있고 자료에 대한 오퍼레이션만을 볼 수 있게 축약한것 다. 제어 추상화 - 프로그램의 액션에 대한 간략화 - 액션 : 서브프로그램 안의 제어 흐름과 같은 개념으로 흐름도나 의사코드 등으로 축약 표현

모듈화
모듈을 별도로 컴파일할 수 있어 모듈을 수정해도 전체 시스템을 다시 컴파일 할 필요가 없음
디버깅에도 도움이 되어 시스템의 문제를 국한시키며 시스템을 고치는 작업이 수월
결합도 및 응집도 가. 결합도
모듈간의 상호 의존하는 정도를 의미
모듈 사이의 의존하는 정도
자료 결합(data coupling) : 모듈간의 인터페스가 자료 요소만 구성된 경우(매개 변수 전달(parameter passing), 공통 자료의 사용(global data), 입출력 장치) => 매개 변수 전달(parameter passing)

class MyClass { public: void doSomething(Set aSet){...} };

=> 내부 자료 데이터

class sneaky { private: luke *luke; public: void sneak() { luke->father = "Darth"; } }; class luke { public: string father; public: luke() { father = "Anakin"; } };

=> 공통 자료의 사용(global data)

double todays_score; class One { public: void set_score(){ todays_score = 10534; } }; class Two { public: void print_score() { cout << todays_score; } };

스탬프 결합(stamp coupling) : 모듈간의 인터페이스로 배열이나, 레코드 등의 자료구조가 전달되는 경우

typedef struct _customerInfo { char name; char address; char phone; char SSN ; } CUSTOMER_INFO ; int ReadCustomerInfo(char ID, CUSTOMER_INFO info) { }; int StoreCustomerInfo(char* ID, CUSTOMER_INFO info) { };

제어 결합(control coupling) : 한 모듈이 다른 모듈에게 제어요소(function code, switch, tag, flag)를 전달하는 경우

int GeneralIORoutine(int flag, void buffer, int size) { if ( flag == 0 ) Read(void buffer, int size) else Write(void buffer, int size) }; int Read(void buffer, int size) { } int Write(void* buffer, int size) { }

공통 결합(common coupling) : 여러 모듈이 공동 자료 영역을 사용하는 경우, 자료의 선언 영역(data scope)이 공통(global)인 경우

char character; Input_and_Output() { Input_char(); Output_char(); } Input_char() { character = getchar(); } Output_char() { putchar(character); }

int xyz = 0; int doSomething(int delta) { xyz += delta; return xyz; }

내용 결합(content coupling) : 한 모듈이 다른 모듈의 일부분을 직접 참조 또는 수정하는 경우, 한 모듈에서 다른 모듈의 중간으로 분기(goto)되는 경우나 다른 모듈의 국부 자료(local data)를 참조하는 경우 => 어셈블리어 프로그램 => goto 문

switch (c) { case '1': goto InputScore; case '2': goto ModifyScore; } InputScore: printf("성적 입력: 공사 중입니다.\n\n"); goto ShowMenu; ModifyScore: printf("성적 수정: 공사 중입니다.\n\n"); goto ShowMenu

결합도에 영향을 주는 요소

구분 인터페이스 복잡도 연결 형태 커뮤니케이션 내용 낮음

높음 단순 명확

복잡하고 불투명 이름으로 모듈 변경

내부 요소로 연결 데이터 제어 정보 복합

나. 응집도 - 모듈안의 요소들이 서로 관련되어 있는 정도 - 응집력의 정도

기능적 응집(functional cohesion) : 잘 정의된 기능적 결합 => 예 : 판매 세금 계산과 같은 이름을 가진 모듈은 한쌍의 동사와 목적어 쌍으로 기술되었으므로 응집력이 강한 모듈
순차적 응집(sequential cohesion) : 모듈안에 있는 하나의 소작업에 대한 결과가 다른 작업의 입력된 경우 => 예 : 다음 거래를 읽고 마스터 파일을 변경함과 같은 모듈은 순차적 응집 관계
교환적 응집(communication cohesion) : 동일한 입력과 출력을 사용하는 소작업들이 모인 모듈 => 출력파일을 출력하고 저장과 같은 모듈의 수행 순서는 관계는 없지만 출력 파일이 같으므로 교환적 응집 관계
절차적 응집(procedural cohesion) : 모듈 안의 작업들이 큰 테두리 안에서 같은 작업에 속하고 입출력을 공유하지도 않지만 순서에 따라 수행될 필요가 있는 경우 => 한 모듈 내에서 다수의 기능 요소들이 배열된 순서대로 수행되지만, 한 기능 요소에서 다음 기능 요소로 자료(data)가 아닌 제어(control)가 넘어가는 경우 => 예 : 화면을 지우고 메뉴를 뿌리고 메뉴 선택 코드를 받는 작업으로 구성 즉 여러 모듈을 하나의 모듈로 강제 통합한 경우를 절차적 응집 관계
시간적 응집(temporal cohesion) : 프로그램의 초기화 모듈 같이 한 번만 수행되는 요소들이 포함된 형태
논리적 응집(logical cohesion) : 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들을 하나의 모듈이 형성되는 경우 => 예 : Edit-data-with-tag라는 이름의 모듈같이 매개 변수에 의하여 서로 다른 작업이 선택되도록 한 것으로 작업 사이에 긴밀한 응집력이 없음
우연적 응집(coincidental cohesion) : 아무 관련 없는 처리 요소들로 모듈이 형성되는 경우
응집력을 판단하는 기준

모듈 기능을 정의한 문장 응집력 복문, 쉼표, 하나 이상의 동사 순차적이나 교환적 응집 시간과 관련된 단어(처음, 다음, 이후 등) 순차적이나 교환적 응집 동사 앞에 단일 특정 객체가 아닌 경우 논리적 응집 초기화, 모두 삭제 시간적 응집

소프트웨어 아키텍처 가. 정의
외부에서 인식할 수 있는 특성을 가진 소프트웨어 구성요소들의 구조 나. 관점(view)

관점(view) 설명 모듈 시스템을 단위 코드의 집합으로 봄 단위코드 : 시스템의 기능 중 일부를 구현 코드구조 : 의존, 상속, 부분 관계 등 컴포넌트와 커넥션 컴포넌트 : 실행되는 시스템에서 고유식별 가능한 단위 컴포넌트 예 : 객체 집합, 프로세스 커넥션 : 상호작용의 수단을 제공 커넥션 예 : 파이프, 소켓, 공유 데이터, 미들웨어 배치 단위 소프트웨어가 어떤 하드웨어 노드에 배치되는가에 관점을 둔 설계

다. 모듈과 컴포넌트의 관계 - 1:1 관계 : 하나의 모듈이 하나의 컴포넌트로 구현 - 1:N 관계 : 하나의 모듈이 복수의 컴포넌트로 구현 - N:1 관계 : 복수의 모듈이 하나의 컴포넌트로 구현 2. 아키텍처 스타일 가. 저장소 구조(repository architecture) - 서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경 - 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호작용 - 예 : 급여시스템이나 은행시스템과 같은 데이터베이스 관리 시스템 - 장점 : 복잡한 자료가 계속 변경되는 업무를 처리하는 응용 시스템에 적합 - 단점 : 중앙 저장소가 급속하게 병목 현상을 일으킬 수 있음, 서브시스템들과 저장소 사이의 결합도가 높아 서브시스템에 영향을 주지 않고 저장소를 변경하기가 매우 어려움 나. MVC(Model View Controller) 구조 - 모델, 뷰, 제어구조라는 세 가지 다른 서브시스템으로 구성 - 모델 서브시스템 : 도메인의 지식을 저장 보관 - 뷰 서브시스템 : 사용자에게 보여줌 - 제어 서브시스템 : 사용자와의 상호작용을 관리 - MVC의 본래의 목적 : 사용자에게 디스플레이 되는 부분과 사용자가 그것을 제어하는 부분으로부터 애플리케이션을 분리하여 보다 간단한 사용자 인터페이스를 개발하는 것 - 일반적인 정보처리단계화 MVC 구조

=> 입력(Input), 처리(Process), 출력(Output) => Input=Controller, Process=Model, Output=View - Model, View, Controller, 간의 관계

Model => Controller로부터 이벤트를 전달받은 Model은 결과를 처리한 다음 디스플레이를 위해 View에게 notification(통지) 함
View => View는 항상 모델의 변화에 따른 통지를 따라 디스플레이 하므로 Model의 통보를 기다리고 수신된 통보에 대해 동의(subscribe) 함 => Model을 View와 독립적으로 유지시키려는 것은 프로그램을 변경 또는 확장해야할 필요가 있을 때 Model을 조금도 변경시키지 않고 View와 Control만을 수정하여 유지보수하도록 하기 위함
Controller => 외부로부터 이벤트가 발생하면 데이터 처리를 위해서 Model에게 알려줌 => View로 향한 화살표는 Controller와 View간의 직접적인 상호작용을 보여줌 => 모든 사용자 외부입력이 Model을 경유하는 것이 아니라 Model의 처리가 필요없이 바로 View로 전달 => 예 : Controller에서 알파벳순으로 되어있는 View의 디스플레이를 요청할 경우 이런 이벤트는 모델에서 데이터 처리가 필요없이 바로 View 디스플레이만 요청만 하는 경우 Model에서 데이터 처리가 필요 없음
MVC 예 => 스프레드시트를 화면에 보여주는 뷰는 셀 모양, 그래프, 차트 등 여러가지가 있음 => 실제 자료는 모델 서브시스템이 한 가지 형태로 보관 => 스프레드시트에 있는 어떤 특정 셀의 정보가 바뀌면 모델 서브시스템은 통보기능(notification)을 이용하여 변경된 내역을 관련된 뷰 서브시스템에게 알리고 통보 받은 뷰 서브시스템은 그래프나 차트에 변경 사항을 반영
장점 : 같은 모델에 대하여 여러가지 뷰가 필요한 상호작용 시스템을 위하여 적절한 구조
단점 : 저장소 구조와 같이 성능의 병목현상이 발생 다. 클라이언트 서버 구조
서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공
서버 : 트랜잭션을 수행하고 데이터의 일관성을 보장
클라이언트 : 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집
클라이언트 서버 시스템은 저장소 구조의 특수한 형태이나 저장소 구조의 중앙 데이터 구조는 한 프로세스에 의하여 관리 되지만 클라이언트 서버 시스템에서는 제한이 없음
웹에서 같이 단일 클라이언트가 수 천개의 서버로부터 데이터를 받을 수 있음 라. 계층 구조
각 서브시스템이 하나의 계층이 되어 하위 층이 제공하는 서비스를 상위 층의 서브시스템이 사용하도록 구성
상위 층은 클라이언트가 되며 하위 층이 서버처럼 작동
표현 방법

Arrow 사이드바

상위 레이어와 하위 레이어 간의 결합도가 높은 경우 사용 레이서 스타일의 변형으로 D는 A, B, C 모두 접근 할 수 있는 영역 표현

=> 예 : TCP/IP 4계층, OSI 7계층이 존재함 - 장점 : 층과 층 사이의 인터페이스 제약만 어기지 않으면 각 층을 필요에 따라 쉽게 변경, 연결된 층의 인터페이스만 맞추어주면 특정 계층을 쉽게 재사용 - 단점 : 각 서브시스템 사이에 복잡하게 관계를 맺고 있어 이를 독립적인 층으로 분리 추상화하기 어려움, 과도한 계층 분할은 서브시스템 사이의 인터페이스로 인하여 성능의 저하를 가져옴 마. 파이프 필터(pipe filter) 구조 - 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복 - 서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프 - 예

=> PS의 출력이 grep에 입력되어 특정 사용자의 프로세스가 아닌것을 모두 제거 => 다음으로 grep 출력은 sort에 의하여 정렬되고 한 화면씩 디스플레이 하는 more에게 보내짐 - 장점 : 사용자의 개입없이 데이터의 흐름이 전환되는 경우 사용 - 단점 : 컴포넌트 사이에 더 복잡한 상호작용이 필요한 시스템의 경우 맞지 않음, 예를들면 정보관리 시스템이나 상호작용 시스템에는 맞지 않음

아래와 같은 간단한 응용에 대한 소프트웨어 아키텍처를 작성하고자 한다. 다음 질문에 답하시오. 영문 문자열을 입력하여 각 문자별 대소문자를 체크하여 대소문자를 바꾸어 출력하는 프로그램이다. 앱력 : ToDayIsHoliDay 출력 : tOdAYiShOLIdAY (1) C&C 뷰(Component & Connector, 프로세스 뷰)를 작성할 때 가장 적당한 아키텍처 스타일을 제시하고 필요한 컴포넌트 커넥터를 제시하시오. (2) 위에서 제시한 아키텍처 스타일에 따라 아키텍처를 작성하시오. (3) 위 응용에 대한 모듈 뷰(논리 뷰)작성을 위한 컴포넌트를 제시하고 아키텍처를 작성하시오

아키텍처 스타일의 의미와 유형 가. 아키텍처 스타일의 의미
아키텍처의 구성 요소와 구성요소들간의 관계들이 사용될 때 작용하는 제약사항과 함께 특화시켜 놓은 아키텍처 집합
뷰를 표현할 때 반복적으로 나타나는 재사용이 가능한 아키텍처의 형태 나. 아키텍처 스타일의 유형

유형 서브타입 설명 데이터중심 (Data-Centered) 칠판형 (Blackboard) - 데이터의 정확성을 위한 품질 특성을 구현이 목적 - 광범위하게 접근되는 데이터 저장소에 대한 접근과 갱신 작업에 초점 저장소형 (Repository) 데이터 흐름 (Data Flow) 일괄 순차형 (Batch Sequential) - 처리 단계 또는 컴포넌트들이 독립적인 프로그램으로 구성하며, 하나의 컴포넌트가 수행을 완료한 후에 다음의 컴포넌트를 수행 - 전통적인 데이터 처리 응용분야에서 사용 파이프-필터형 (Pipes and Filtered) - 연속적인 컴포넌트들에 의한 데이터의 점진적 변형 구조 - 필터 : 데이터 스트림(stream) 변환기 - 파이프 : 필터와 필터 사이에 존재하면서 단순한 데이터의 이동을 담당 가상머신 (Virtual Machine) 번역기형 (Interpreter) 소프트웨어 시스템의 이식성 품질 특성을 성취하는데 목적을 둔 스타일로서 해당 소프트웨어 시스템이 구현될 하드웨어나 소프트웨어에 직접적인 관련이 없는 기능들에 대한 시뮬레이션을 수행 규칙기반 시스템형 (Rule-Based System) Call and Return 주프로그램과 서브루틴 (Main Program and subroutine) 하나의 프로그램을 작은 단위의 서브루틴으로 나눔으로서 소프트웨어 시스템의 수정성 품질 특성을 성취 원격 프로시져 호출 (Remote procedure call architecture) 소프트웨어 시스템을 네트워크로 연결된 컴퓨터상에서 실행되는 작은 단위의 서브루틴으로 구성하여 분서처리 Layered - SW를 계층이라는 단위로 분할하여, 각 계층은 오직 이웃한 계층끼리만 통신 - 시스템의 수정성과 이식성 품질특성 제공

주어진 문제 분석과 C&C 뷰 기반 아키텍쳐 스타일 제시 가. 주어진 문제 분석
문자열을 받아서 대소문자 변환 후 출력하는 애플리케이션
필요 구성 요소 : 입력 모듈, 변환 모듈, 출력 모듈 나. 아키텍처 스타일 선정

다. 컴포넌트와 커넥터 제시

컴포넌트(Component)은 데이터 흐름상 데이터에 영향을 주는 기능을 기준으로 추출함
커넥터(Connector)은 컴포넌트와 컴포넌트 사이의 의미관계를 기준으로 추출함
Pipe & Filter 아키텍처 스타일에 따른 아키텍처 작성
Filter : 위에서 도출한 입력, 분리, 대문자화, 소문자화, 결합, 출력 컴포넌트를 필터로 표현
Pipe : 위에서 도출된 커넥터가 파이프에 해당함
위에서 도출한 Filter(컴포넌트)와 Pipe(커넥터)를 도식화 하여 아키텍처를 작성함
모듈 뷰(논리 뷰)작성을 위한 컴포넌트 제시 및 아키텍처 작성 가. 모듈 뷰(논리 부) 작성을 위한 컴포넌트 제시
분리, 소문자화, 대문자화, 결합 컴포넌트는 C&C 뷰와 1:1로 매핑됨
모듈 뷰에서는 실제 시스템이 동작을 하는데 필요한 컴포넌트인 주 모듈, 구성 등이 추가됨
C&C View에서 표현된 입력과 출력은 모듈 뷰에서 Stdio 라이브러로 대체됨.

아키텍쳐의 재활용과 품질속성을 달성하기 위한 아키텍처 스타일 가. 아키텍처 스타일
아키텍처를 구성하고 있는 컴포넌트 유형과 실행시간에 이루어지는 그들간의 제어, 데이터 전송 패턴 나. SW 생명주기별 공통 문제점에 대한 해결 방안

요구사항 분석 설계 구현 아키텍처 스타일 MVC 패턴 디자인 패턴 이디엄 의사소통, 표준화, 경험의 반영

나. 아키텍처 스타일의 구성요소

구성요소 설명 사례 Component Type 아키텍처의 기본구성요소로 정의된 최소기능을 수행하는 단위 Process, Object Connector Type 컴포넌트 사이의 상호작용 메커니즘 Event, Pipe Topology 컴포넌트의 기하학적 레이아웃 Start, Ring, Layered Constraint 컴포넌트간의 실행규칙, 순서등의 제약조건 Layered에서 방향성 Benefit on Style 해당 패턴 사용시 예상되는 이익/효과에 대한 정량적 보안성 강화

다. 아키텍처 스타일과 디자인 패턴의 관계 및 비교 - 개념도

아키텍처 스타일 및 디자인 패턴 비교

구분 아키텍처 스타일 디자인 패턴 목적 아키텍처의 재사용과 품질속성의 달성 설계과정의 공통적인 문제점에 대한 해결 관점 아키텍트 관점 설계자 관점 의미 아키텍처 프레임워크 제공 클래스 단위의 가이드 제공 대표모델 Layered, Pipe&Filters 생성/구조/행위 패턴 RUP 단계 Inception, Elaboration Construction, Transition

I. SW 아키텍처 평가방법 가. SW 아키텍처 평가방법 정의 - 제시된 SW 아키텍처가 개발될 SW에 대해 요구되는 품질 특성을 충족시킬 수 있는가를 아키텍처 수준에서 평가하는 작업 - SW 아키텍처와 요구사항을 입력하여 시행함 나. SW 아키텍처 평가 방법론 유형

구 분 설 명 Scenario based - 직접적으로 품질요소를 위해 미리 정의된 Profile에 의존하여 평가하는 방식 - 시나리오에 기반하므로 평가결과도 정밀 - ATAM, SAAM 등 Simulation based - BMT와 같은 시뮬레이션 기반 평가 방식 Mathematical model based - 기준 모델을 수치화하고 이를 기초로 평가하는 수학적 기반 모델 Experience based - 정량적인 분석이 어려우므로, 경험기반의 평가 방법

다. SW 아키텍처 평가 유형

유형 설 명 ATAM - Architecture Trade-off Analysis Method - 시나리오 기반의 모든 품질요소(Quality Attributes)를 평가하고 품질 속성들이 서로 어떻게 trade-off(상충)되는 지까지 밝힘. - 순서 : 아키텍처 평가준비->평가작업 수행->후속보고 진행 단계 CBAM - Cost Benefit Analysis Method - ATAM에서 부족한 경제적 평가 부분을 보강한 프로세스로, 비용과 일정간의 관계를 파악하여 아키텍처 전략적 비용 측정 - 품질속성 도출하여 비용대비 효과가 좋은 아키텍처 결정 SAAM - Software Architecture Analysis Method - 최초로 정리된 평가방법, 다양한 수정가능성들의 관점에서 아키텍처분석 ARID - Active Reviews for Intermediate Designs - 완성되지 않은 아키텍처에 집중, 시나리오는 적절한 요구사항을 검증에 사용

II. 아키텍처 트레이드 오프 분석방법 ATAM 가. ATAM(Architecture Trade-Off Analysis Method) 개요 1) ATAM의 정의 - 품질속성 요구사항과 비즈니스 목표달성을 위한 아키텍처 결정사항들에 대해 평가하는 방법론 2) ATAM의 특징 - 서로 다른 품질 속성 사이의 상충점(Tradeoff point) 분석 - 전통적인 레거시 시스템 분석시 사용 - Product Line개념이 들어간 여러개의 제품군 개발에서 효과적 3) ATAM의 기본 개념도

나. ATAM의 단계 1) 일반적인 ATAM의 단계

단계 수행 내용 단계 0 - 시스템 아키텍처와 ATAM 메소드에 대한 가이드라인 교환 및 이해 단계 1 - 소수의 이해당사자들이 모여 Top-Down 분석방법을 기반으로 ATAM 평가팀에게 자세한 아키텍처 정보들을 소개하고 분석 단계 2 - 다양한 이해당사자들이 모여 단계1에서 얻은 결과를 바탕으로 검증 - 단계1의 Top-Down분석이후, 단계2에서는 Bottom-Up으로 분석 단계 3 - ATAM 평가팀이 분석을 통해 얻은 자료를 바탕을 최종 보고서 작성 - 사후검토(Postmortem meeting) 실시 및 아키텍처의 잘못을 핵심 이해당사자들로부터 피드백

2) ATAM의 단계와 스텝

스텝/단계 단계0 단계1 단계2 단계3 단계1 : ATAM 소개

단계2 : 드라이버 소개 **

단계3 : 아키텍처 소개 **

단계4 : 아키텍처 접근법 식별

단계5 : 품질속성 유틸리티 트리 만들기

단계6 : 아키텍처 접근법 분석

단계7 : 브레인 스토밍과 시나리오 우선순위 매기기

단계8 : 아키텍처 접근법 분석

단계9 : 결과 보고

다. 프로젝트 성공을 위한 필수 활동 - 미 항공우주국(NASA)나 Boeing 등 많은 기업에서 ATAM을 사용 - 큰 규모의 프로젝트에서 비용이 많이 절감 - 소규모 프로젝트나 여러가지 제품군을 동시에 개발하는 프로젝트라인 제품군에는 조금 더 검증 필요 - Product Line군에는 EATAM(Extending ATAM)을 권장 III. 아키텍처 설계 결정을 위한 경제적 접근법 CBAM 가. CBAM(Cost Benefit Analysis Method)의 개념 - 경제적 의사결정에 대한 요구를 충족시키기 위해 SEI에서 ATAM을 바탕으로 S/W 아키텍처 분석에 중점을 둔 경제적 모델링 방법 - 아키텍처 결정의 비용과 이익을 모델화해서 최적화하기 위한 수단 - ATAM의 종료시점부터 시행, ATAM의 결과물을 바탕으로 수행 나. 기존 아키텍처 평가 방법의 한계 - 기술성 : 시스템이 달성해야 하는 품질속성 - 경제성 : 시스템 구축시 드는 비용과 제공시 품질에서 얻을 수 있는 이득 - SAAM, ATAM은 아키텍처의 “기술성” 측면을 다루는 데는 뛰어나지만 아키텍처의 “경제성” 측면은 다루지 않음 다. CBAM의 배경

CBAM으로 ROI를 도출해 아키텍처 전략선택에 활용 가능 라. CBAM의 특징
ATAM이 끝나고 나서 ATAM의 산출물을 기반으로 시작하는 경우 많음
아키텍처 접근법을 실현하는데 필요한 비용과 아키텍처 접근법을 적용했을 때 달성가능한 품질속성 이익을 측정하고, 이 이익을 “효용(utility)”으로 표현
비용과 이익으로부터 “투자대비효과(ROI)”를 계산
의사결정자는 아키텍처 접근법을 선택할 때 ROI를 판단근거로 활용가능 마. CBAM의 구현(프로세스)

I. SW Architecture의 사실상 표준, 4+1 View Model의 개념 가. 4+1 View Model의 정의 - 고객의 요구사항을 정리해놓은 시나리오에 대하여 4개 관점에서 접근하여 설명하기 위한 Software적인 접근 방법 나. 4+1 View Model의 필요성 - Box 중심의 화살표를 이용한 Diagram 표시 방식의 단순한 View Model 표현의 방법적 한계 극복 - 시스템의 기능적, 비기능적 요구사항을 만족시키는 아키텍처의 등장 - 갈수록 진화하는 시스템의 복잡성으로 인한 View Model 체계화 II. 4+1 View Model의 구성도 및 구성요소 가. 4+1 View Model의 구성도

아키텍처는 4개의 View로 체계화 된 후 Use-Case 또는 Scenario로 불리는 다섯번째 View로 구성 나. 4+1 View Model 구성요소 설명

뷰/관점 내용 Logical View (설계관점) - 상위 수준에서 시스템의 논리적인 구조와 행위(behavior)를 클래스, 인터페이스, 협력관계(collaboration)로 정의 - 시스템의 기능 요구사항을 설명 - 설계 구성요소들과 그 요소들 사이의 관계 표현 - 관점 : 분석/설계자, 구조에 주안점 - 비즈니스 컴포넌트식별 시작점, 공통 컴포넌트 군 식별 - Class Diagram, Sequence Diagram Process View (프로세스관점) - 프로세의 분해에 초점을 두며 프로세스에 대해 컴포넌트를 할당하는 것을 보여준다 - 관점 : 시스템 통합 담당자, 성능에 주안점 - Sequence Diagram, Collaboration Diagram Implementation View (구현관점) - 독립적으로 실행되는 컴포넌트와 이들간의 관계를 정의 - 관점 : 프로그래머 - 개발 표준 활용 : Layer 기준, Layer의 역할과 책임, 구현 메커니즘 제공 - 역할 ① 시스템을 개발팀 단위에서 다룰 수 있는 크기로 분할 ② 모듈을 나누는 원칙을 설명 ③ 모듈에 따라 요구사항을 할당, 개발팀 구성, 진척사항 관리 등의 프로젝트 활동 수행 ④ 모듈들이 모여 시스템을 구성하는 방법 설명 - Component Diagram Deployment View (엔지니어관점) - 실행되는 시스템 하드웨어와 소프트웨어 관계를 정의 - 관점 : 시스템 엔지니어 - 활용 : 시스템 구성시 정의된 토폴로지 및 사양참조, SW 및 애플리케이션, 배포 기준 제공 - 역할 : ① 실제 동작하는 모듈들이 어떤 HW에 설치되어 운영되는지 설명 ② HW 이중화 등 HW 구성도 설명 Use Case View (사용사례관점) - 시스템의 외부 사용자 관점에서 사용 사례(use cases)와 이들간의 관계를 정의 - 시스템 아키텍처를 도출함 - 관점 : 사용자, 기능성에 주안 - 요구분석 단계에 사용되는 관점으로 자세한 내부 설계에는 사용되지 않음 - 다른 뷰를 통합 하는 뷰로서 시스템의 행위를 다룸 - 나머지 4개의 뷰를 도출, 아키텍처 검증의 근간이 됨 - 시스템을 사용하는 이벤트와 기능위주로 표현한다 - 사용자 기능 중심(비즈니스 모델링 수행) - USE CASE DIAGRAM

다. Logical View 표현 Example

라. Process View 표현 Example

마. Physical View 표현 Example

바. Scenarios View 표현 Example

I. 4+1 View Model의 구성별 특징

    View

구성 Logical Process Development Physical Scenarios component 클래스 task 모듈 서브시스템 node Step, script Notation (표시법) Booch notation (OMT)

Booch notation (module, subsystem layer) Deployment Test& development Logical view와 유사 관점 End-user system integrator 개발자 매니저 System Engineer All user evaluator 관심요소 기능 성능, 가용성, S/W fault-tolerant Organization Portability Line-of-product Scalability 성능 가용성 System consistency Tool Rose UNAS/SALE DADS Apex SoDA UNAS DADS Rose

IV. 4 + 1 View Model의 향후 발전 방향 - View 모델을 통하여, 개발자나 사용자가 다양한 측면 반영으로, 시스템 개발의 효율성을 증대시키고, 소프트웨어의 유지보수의 운영을 극대화 시킴 - 현재 널리 쓰이고 있는 모델 언어인 UML을 도입하여, 소프트웨어 개발을 하는데 있어, 실용성과 사용의 편의성을 제공함.

위치 View(시각) View Point(관점) Concern(관심사) UML Diagram 비고 중앙 Use Case View(사용사례 시각) End-user(최종 사용자) Functionality(기능) Use Case 사용 시나리오(사용자 기능) 좌상 Logical View(논리적 시각) Analytics/Designers(분석자/설계자) Structure(구조) Class Sequence 데이터(기능)(시스템 기능) 좌하 Process View(프로세스 시각) System Integrators(시스템통합/품질담당자) Performance(성능) Scalability(확장성) Throughput(처리속도) Sequence Collaboration 프로세스 (비기능) 우상 Implementation View(구현 시각) Programmers(개발자) Software Management(소프트웨어 관리) Component 구현 우하 Deployment View(배치 시각) System Engineering(인프라 담당자) System Topology (시스템구성) Delivery(전달) Installation(설치) Communication(통신) Delployment 배치/설치

SA가 표현해야 하는 내용, 관계정의 표준 프레임워크 IEEE1471 가. IEEE 1471의 정의
SW집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들간의 관계를 제공하는 아키텍처 명세를 위한 표준 메타 모델
아키텍처를 어떻게 개발할 것인가는 다루지 않고 유용한 명세를 위해 포함해야 할 요소/내용 규정함 나. IEEE 1471의 중요성

중요성 설명 표준화 아키텍처와 관련된 용어 및 개념의 통일 중립성 모델링언어, 방법론 제시하지 않음, 개발 상위 레벨에서의 SA의 표현 유연성 다양한 규모의 시스템 구축 시 적용 가능 의사소통 요구사항/설계의 차이를 개선, 이해관계자 관점에서의 표현

IEEE1471의 개념적 모델 및 구성요소 가. IEEE 1471의 개념적 모델
아키텍처 개발에 관련된 Best Practice기반 국제표준으로 필요/불필요한 정보를 구분, 일관성 있게 조직화 할 수 있도록 지원 나. IEEE 1471의 구성요소

구성요소 설명 Mission Environment안에서 한 명 이상의 Stakeholder들이 의도하는 System의 목적/사용/운영방법 Environment System에 영향을 주는 요인으로 개발, 운영, 정치 등의 외부 요인 등으로 시스템에 영향을 주는 요인 System 각 애플리케이션들, 서브 시스템들, 시스템의 집합, 제품라인, 제품 군 등의 구현체 Stakeholder 한 명 이상의 System에 대한 이해 당사자로 각자 다른 System에 대한 Concern을 가지고 있으며 개인이나 기관이 될 수 있음 Concerns System의 성능, 유연성, 보안, 분배, 진화 등을 포함한 한 명 이상의 Stakeholder들에게 중요한 System의 개발이나 운영 등 측면 Architectural description System구축 시 Environment에 적합하도록 추천하는 수행방법으로 Architecture가 기록되는 방법 View 이해관계자들과 이들이 가지는 생각이나 견해로부터 시스템을 표현 Viewpoint View를 구성하기 위한 규칙을 정의하는 패턴이나 템플릿 Rationale 선택되어 설계된 아키텍처에 대한 논리적 근거

IEEE 1471에서 규정하는 아키텍처를 작성하기 위한 활동 가. 아키텍처 관련 문서의 파악 나. 이해관계자, 그들의 역할 및 아키텍처상의 관심 사항의 파악 다. 뷰포인트의 선택 및 명세 라. 뷰의 명세 마. 뷰들 간의 존재하는 불일치성의 파악 및 기록 바. 선택되어 설계된 아키텍처에 대한 논리적 근거(Rationale) 작성

객체지향 설계

객체지향 설계 가. 모델
기능적 모델 : 사용자에게 보이는 외부 기능
정적 모델 : 객체 모델이라고도 하는데 시스템을 구성하는 요소들, 즉 객체의 관계를 표현 => 정적 : 시간적인 요소가 개입되지 않은 즉 변하지 않는 구조적인 관계를 의미
동적 모델 : 시간적인 요소가 고려된것을 동적 모델, 시간이 흐름에 따른 객체의 상태 변화라든지 메시지 호출 순서 등을 나타냄
사용 사례 다이어그램 : 요구를 파악하기 위하여 시스템의 기능적인 측면을 모델링
순서 다이어그램 : 시스템 내부 관점에서 객체들의 상호작용을 나타낸 것으로 사용 사례 단위로 그리게 되므로 기능적 모델과 밀접한 관련을 맺고 있음 나. 객체지향 단계와 다이어그램

모델 다이어그램 분석 설계 구현 기능적 모델 사용 사례 ◯

정적 모델 객체 ◯ ◯

클래스 ◯ ◯ ◯ 컴포넌트

◯ ◯ 배치

◯ 동적 모델 인터랙션 ◯ ◯

액티비티 ◯ ◯

상태 ◯ ◯

객체지향 개념(객체, 클래스, 캡슐화, 상속, 다형성, 객체사이의 관계) 가. 구조적 방법과 객체지향 방법 차이점

나. 객체와 클래스 1) 객체 - 필요한 자료구조와 이에 수행되는 함수들을 가진 하나의 소프트웨어 모듈 - 각 객체가 자료구조를 갖는다는 것은 각 객체가 어떤 상태(state)를 가지고 있다는 의미 - 상태(state)와 행위(behavior)를 가진 것으로 비슷한 객체의 구조와 행동이 공통 클래스로 선언 - 객체=상태(state) + 행위(behavior) + 정체성(identity)

2) 클래스 - 객체의 타입(object type)이 존재하며 이를 클래스(class)라고 함 - 같은 클래스에 속하는 개개의 객체를 그 클래스의 인스턴스(instance)라고 함 - 클래스를 정의하기 위해서는 클래스가 가지는 속성(attribute)을 도출하여야 함 - 각각의 객체들이 갖는 속성과 적용 연산을 정의하고 있는 틀(templet)

다. 객체 사이의 관계 1) 연관 - 객체가 다른 객체의 서비스를 사용한다면 두 객체 사이는 연관(association) - 어떤 객체에서 다른 객체로 메시지가 흘러간다는 것을 의미 - 가시성(visibility) : 객체의 접근 가능성을 뜻하는 것으로 A객체와 B객체가 연관이 있다면 A객체에서 B객체를 알고 있고 접근 가능 - 연관 방법

방법 내용 전역선언 연관된 객체를 전역으로 선언하여 클라이언트 객체가 접근할 수 있게 하는 방법 연관된 객체가 모든 다른 객체에게 오픈 즉 정보은닉이라는 측면에서 바람직한 방법이 아님 메서드 연관된 객체를 클라이언트 객체의 메시지 호출 오퍼레이션의 매개변수로 만드는 방법 연관 객체가 메서드의 매개변수가 되면 그 객체는 어딘가에 있는 메서드를 통하여 이를 접근 데이터 멤버 연관된 객체를 클라이언트 객체의 일부로 만드는 방법 연관된 객체가 클라이언트 객체 선언 안에 데이터 멤버로 정의 클라이언트 객체가 소멸되면 연관된 객체도 소멸되는 공동 운명체 연관된 객체와 클라이언트 객체가 서로를 공유하고 가시화 포인터 연관된 객체를 클라이언트 객체에서 선언하는 방법 클라이언트 객체가 연관된 객체의 포인터를 갖도록 선언

2) 집합관계 - 전체 개념(whole)과 부분 개념(part) 사이의 관계 - A객체가 B객체와 C객체의 집합 개념이라면 B와 C는 A안에 포함 - 예

class Disk { private : Track *tracks; disk information; ......................... }; class Track { private : sector sectors[MAX]; ......................... }; class sector { private : ....................... };

=> Disk 클래스는 Track 클래스의 객체에 대한 포인터를 그 안에 가지고 있고 이 포인터는 객체 밖에서 접근할 수 없음 => Track 클래스의 정의 의하면 각 객체가 Sector 클래스 타입의 객체들의 배열을 그 안에 포함하고 있음 => Disk는 여러 Track으로 구성되며 각 Track은 Sector로 구성되고 있음을 의미 라. 객체지향 개념도

위임의 개요 가. 위임의 정의
객체의 메서드(Method)를 보다 효율적으로 사용하기 위하여 특정 메서드 자체를 캡슐화 할 수 있게 만들어 주는 방법
특정 객체가 특정 기능을 수행하는 메서드를 다른 객체에 의존할 수 있게 해줌
즉 위임이란 자신에게 전달된 메서드를 대신 실행해 주는 역할
C, C++의 함수포인터와 유사한 개념 나. 상속성의 문제점과 위임의 특징 상속의 문제점 위임의 특징 상속은 클래스를 활용한 화이트박스 재사용으로 재사용의 한계가 존재 인터페이스를 통한 재사용(블랙박스 재사용) 상속의 경우 부모 클래스의 구현요소가 서브 클래스에 보임(캡슐화) Delegate의 인스턴스 호출은 포인터가 가리키는 Method를 실행하는 것을 의미 런 타임시 상속받은 부모 클래스 변경 불가 런 타임시 동적 바인딩
위임의 구현 사례 및 상속과의 비교 가. 위임의 구현 사례

1) 델리게이트 선언 2) 델리게이트가 대신할 메서드 3) 객체(Instance) 생성 4) 델리게이트 생성 5) 델리게이트를 이용한 호출 - 하나의 클래스에서 특정 메서드만 필요로 할 경우 델리게이트(delegate) 활용 나. 상속과의 비교

구분 상속 위임(델리게이트) 바인딩 컴파일시 런 타임시 캡슐화 부모 클래스 내부가 서브 클래스에서 보임 클래스 내부는 보이지 않고 Interface를 통해서만 메시지 전달 재사용 화이트박스(클래스) 재사용 블랙박스(인터페이스) 재사용 장점 재사용 구현용이 실행 시간에 동적으로 활용 다형성 등 객체지향 특성 활용용이 클래스의 수정 등 변경 영향이 적음 단점 부모 클래스의 변경이 서브 클래스에 직접적 영향을 미침 이해의 어려움 런 타임시 동적으로 정의되므로 테스트 수행의 어려움

※ 상속(inheritance) - 상위 클래스가 갖는 속성과 연산을 그대로 물려받는 것을 의미 - 슈퍼 클래스(superclass) 및 서브 클래스(subclass)로 구성 ※ 다형성(Polymorphism) : 서로 다른 객체가 동일한 메시지에 대해서 고유한 방법으로 응답할 수 있는 능력으로 메시지 해석을 수신 객체에 맡긴다.

“Polygon” 클래스가 갖고 있는 "draw"함수를 하위클래스인 “Triangle”과 “Circle”에서 재정의하여 서로 다른 기능을 수행하도록 한다.
다형성은 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있게 함
다형성 UML 예
다형성 종류 : overloading, overriding
위임(델리게이트)의 활용 가. 디자인 패턴의 구현 원칙으로 상속보다 위임의 사용이 강조됨 나. Proxy 패턴 등에서 활용 가능 다. 특정 클래스의 특정 메서드만 필요로 할 경우 활용 ※ Proxy 패턴 : 다른 객체에 접근하기 위해 중간 대리 역할을 하는 객체
추상클래스와 인터페이스

구분 추상클래스 인터페이스 공통점 모두 클래스 임 하위 클래스에서 모든 추상 메서드를 구현해야 함 차이점 추상메서드 외 일반 멤버 변수와 메서드를 가질 수 있다 추상메서드와 static final 변수만 사용 extends를 사용 Implements를 사용 단일 상속만 가능 중복 구현 가능 작업의 레벨 분할을 위해서 사용 공동 작업을 위한 상호간의 인터페이스를 위해 사용

오버로딩 및 오버라이딩의 개요 가. 오버로딩(Overloading)의 정의(함수의 중복 정의)
이름은 같고 매개변수의 타입 혹은 개수가 다른 함수들의 정의를 허용하는 함수 다. 오버라이딩(Overrding)의 정의(함수의 재정의)
자식Class에서 부모Class에 선언한 멤버 함수와 인자 그리고 반환 타입이 모두 동일한 형태의 멤버함수(부모Class에 선언된 형태의 함수를 자식Class에서 다시 선언)
함수를 자식 클래스가 재정의할 수 있게 해주는 기능
오버로딩(Overloading) 설명 가. 예제코드

나. 결과 값

예제코드에서 주석 처리된 부분을 풀면 아래와 같이 에러 발생 error C2556: 'int cdecl func(int)' : overloaded function differs only by return type from 'void cdecl func(int)'
오버로딩은 리턴타입이 다른 것만으로는 허용되지 않는 않음 즉 void func(int a)와 int func(int a)와 같은 형식은 오버로딩이 아님
오버라이딩(Overriding) 설명 가. 예제코드

나. 결과 값

캡슐화(Encapsulation)와 정보은닉 가. 캡슐화 정의
서로 관련성이 많은 데이터들과 이와 연관된 함수들을 묶어서 처리하는 개념 나. 캡슐화 목적
내부 데이터의 보호 : 외부에서의 직접적인 데이터 접근 및 조작 미허용
모듈 독립성 향상 : 데이터와 함수의 결합 다. 캡슐화 기본원리
정보은닉은 외부객체에 내부 로직 및 구조, 데이터를 숨기는 것(메서드만 허용)
캡슐화는 정보은닉을 확장하여 내부 데이터 및 메서드를 묶어 처리하는 개념 라. 캡슐화 특징
변경이 발생할 때 부작용의 전파를 감소시킴
컴포넌트 재사용을 용이하게 해준다.
인터페이스는 단순해지고 시스템 결합도는 낮아짐 마. 캡슐화 장/단점

장점 단점 모듈 독립성 : 연관관계 최소화 의사소통 및 문서화 미흡시 개발생산성 저하 가능(해석 및 디버깅 등 어려움) 재사용성 향상 캡슐화 설계 및 구현 착오시 내부 데이터의 직접 접근 → 무결성 오류 정보은닉을 통한 내부 데이터 일관성 유지

바. 캡슐화 설계 및 구현시 유의사항 - 클래스 연산자 및 속성의 접근 지정자(Access Modifier) 설계 유의 - public(모든 클래스 접근), private(클래스 내부에서만), protected(Package 내부만)등 사. 캡슐화 개념도

정보은닉 간단한 예제

include

class Car { private: char Engine; char Gear; public: void SetEngine(char e) { Engine = e; } void SetGear(char g) { Gear = g; } char GetEngine() { return Engine; } char GetGear() { return Gear; } }

int main() { Car Matiz; Matiz.SetEngine(m); //매개변수 m은 경차전용 M-TEC MPI 엔진으로 가정한다. Matiz.SetGear(d); // 매개변수 d는 기어 D 상태 cout << GetEngine() << endl; cout << GetGear() << endl; return 0; } - Car 클래스의 멤버변수들을 컨트롤 할 수 없다. 왜냐하면 변수들을 Car 클래스 내부에서만 사용하도록 private 선언을 하였기 때문에 외부에서 컨트롤 할 수 없다.

정보은닉이라 함은 말 그대로 정보를 은닉하는 것을 말하며 정보은닉을 통해 얻을 수 있는 이점은 클래스 내부 변수들을 외부에서 직접적으로 제어하지 못하게 막음으로써 항상 올바른 값만을 넘겨받아 작동할 수 있게 한다.
장점 => 모듈 사이의 결합을 줄이고 시스템의 유지보수를 쉽게 만듦 => 소프트웨어 개발에서 복잡함을 다루는 중요한 수단 => 데이터를 관리하려는 관점과 데이터를 사용하여 원하는 결과를 얻으려는 사용 관점을 분리
캡슐환 간단한 예제

include

class Car { private: char Engine; char Gear; public: void SetEngine(char e) { if(e == 1) //1 은 경차전용 엔진이라 가정한다. Engine = e; } void SetGear(int g) { Gear = g; } char GetEngine() { return Engine; } char GetGear() { return Gear; } char Move() { if(Gear == 'd') 전진하라. if(Gear == 'b') 후진하라. } } int main() { Car Matiz; Matiz.SetEngine(m); //매개변수 1은 경차전용 M-TEC MPI 엔진으로 가정한다. Matiz.SetGear(d); // 매개변수 6은 6단 기어라 가정한다. Matiz.Move(); cout << GetEngine() << endl; cout << GetGear() << endl; return 0; } - 자동차를 움직이는 기능을 갖는 함수 Move()를 Car 클래스 내부에서 선언해줌으로써Car 클래스 내부에는 자동차와 관련된 기능들이 모이게 되었다. - 이처럼 한 클래스 내부에 관련있는 함수와 변수들을 두는 것을 캡슐화 한다고 말한다. - 캡슐화가 가져다주는 이점은 예를 들어 위의 Car 클래스를 가지고 마티즈 자동차를 여러대 만들었다고 생각해보자. 그런데 만약 마티즈 자동차가 후진할 때 이상한 현상이 생겼다고 해보자. 이때 여러대 마티즈의 후진할 때 문제를 한번에 해결할 수 있는 방법은 Car 클래스 내부에 있는 Move()함수만을 확인해 보면 해결된다. 만약 자동차와 관련된 Move()함수가 다른 클래스에 있다고 하면 문제가 생겼을 시 Move()함수를 찾기위해 애를 써야 할 것이다.

OMT(Object Modeling Technique) 방법론 가. 방법론 모델 종류
객체 모델(Object Model)
동적 모델(Dynamic Model)
기능 모델(Functional Model) 나. 방법론 모델 설명

구분 설명 다이어그램 객체 모델 (Object Model) 시스템의 객체들을 규명하고 객체들에 대한 정적 구조와 객체들의 관계를 나타냄 클래스 다이어그램, 서브 시스템 다이어그램, 객체 다이어그램 동적 모델 (Dynamic Model) 시스템 객체들의 상호작용을 표현한다. 즉, 시간의 변화에 따른 시스템의 변화를 설명하며, 시스템의 제어적 측면을 표현 상태전이(State Transition) 다이어그램, 이벤트 추적(Event Trace) 다이어그램 기능 모델 (Functional Model) 시스템이 어떠한 기능을 수행해야 하는지를 나타냄 객체 메시지(Object Message) 다이어그램, 데이터 흐름(Data Flow) 다이어그램

부치(bootch) 방법론 가. 정의
국방, 상업 등 대규모 시스템 구축 경험을 기반으로 하여 부치가 제시한 방법론 나. 특징
시스템 아키텍처에 초점을 둔다.
시스템을 다양한 관점에서 분석하게 한다.
반복적이고 점증적으로 개발하게 하는 프로세스이다.
OOSE(Object-Oriented Software Engineering) 방법론 가. 정의
야콥슨이 제안한 방법론이며, 통신, 금융 업계에서 적용한 방법론 나. 특징
유즈케이스를 중심으로 하여 개발 과정을 진행
유즈케이스 : 분석/설계를 거쳐 실체화되고, 개발 과정에서 구현되며, 테스트를 통해 검증되는 ‘시스템의 중요한 단위’

객체지향 모델링의 표현방법 UML의 개요 가. UML(Unified Modeling Language)의 정의
객체모델링 기술과 방법론을 표준화한 것으로써 객체지향 모델링을 위한 표기법
요구분석, 시스템설계, 시스템 구현 등의 개발 과정에서, 개발자간의 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어 나. 등장배경 및 필요성
객체지향 모델링을 위해 학자들마다 중복되고 일부 다른 방식으로 표현
체계적인 모델링 방법을 표준화를 위해 3명의 학자가 주장하는 표기법의 통일이 필요하게 됨
객체지향 시스템 개발 전 과정(Life Cycle)에서 개발자와 사용자간에 표준화된 의사소통 방식 필요 다. UML의 관점
기능적 관점 : 사용자 측면에서 본 시스템의 기능을 나타내고 UML에서는 주로 분석 단계에 사용하는 사용 사례 다이어그램으로 표현
정적 관점 : 시간 개념이 포함되지 않음, 주로 시스템 구조적 측면을 나타냄, 클래스나 객체들의 관계, 클래스의 그룹이 어떤 의존관계에 있는지를 나타내는 다이어그램
동적 관점 : 시간 개념이 포함, 특정한 시각에 시스템의 동작을 마치 스냅 사진으로 찍어 놓은 것처럼 나타냄, 어떤기능을 실행하고 있는 시스템의 상태나 기능 실행하는 순간 협력하는 객체들을 나타내는 다이어그램 라. 특징
단순 표기법이라기 보다는 사용하는 형식과 각각의 표기에 의미를 가진 언어
이용 시 개발자간 의사소통 원활
개발규모, 개발 프로세스, 언어에 관계없이 적용 가능(Method 아님)
객체지향 개발만을 위한 것이 아니라, 통합모델링 도구로서 다른 모델을 모델링 시에도 사용 가능

마. UML의 구성요소

구 성 내 용 View 모델화된 시스템의 서로 다른 모형 제공 Diagram View의 내용을 나타내기 위한 9가지 다이어그램 제공 모델요소 (Model Element) 객체지향 개념을 표현하기 위해 사용되는 요소 클래스, Object, Operation, 메시지, 관계종속성, 일반화 등 General Mechanism 모델 요소에 대하여 여분의 주석 정보와 의미를 제공함

바. UML Views - 모델화된 시스템의 서로 다른 유형(4 + 1 View)

View 내 용 Use Case View - 시스템을 사용하는 이벤트와 기능 위주로 표현(Use Case Diagram) - 시스템의 요구분석 단계에서 사용되는 관점 Logical View - 시스템 내부의 클래스와 컴포넌트를 파악하고 기술(Class Diagram, Object Diagram) - 객체 모델을 의미하며 클래스 다이어그램으로 나타냄 Process View - 시스템의 내부구조 즉 클래스와 클래스의 관계 및 상호작용에 초점(Sequence Diagram, Collaboration Diagram) - 동적 모델을 의미하며 Sequence 다이어그램과 Collaboration 다이어그램으로 나타냄 Component View - 물리적인 시스템을 조립, 배포하는데 사용되는 컴포넌트와 파일들로 구성(Component Diagram) - 대규모 시스템을 서브시스템으로 나눌 때 사용 Deployment View - S/W가 H/W의 어떤 부분에 배치될 것인지를 표현(Deployment Diagram)

정적 모델(static model)과 동적 모델(dynamic model) 가. 정적 모델
클래스 다이어그램 : 클래스의 관계를 나타나는 다이어그램
객체 다이어그램 : 객체의 정적인 구조를 나타내는 다이어그램
컴포지트 다이어그램 : 컴포넌트의 합성구조와 커넥션을 나타내는 다이어그램
컴포넌트 다이어그램 : 코드 구조를 나타내는 다이어그램
패키지 다이어그램 : 패키지로 선언한 모듈의 구조를 나타내는 다이어그램
배치 다이어그램 : 소프트웨어의 하드웨어 배치를 나타내는 다이어그램 나. 동적 모델
인터랙션 다이어그램 : 객체들 사이의 메시지 교환을 나타내는 다이어그램
상태 다이어그램 : 하나의 객체가 가질 수 있는 상태와 상태의 변화에 의하여 동작을 나타내는 다이어그램
인터랙션 다이어그램 : 순서 다이어그램, 커뮤니케이션 다이어그램, 인터랙션 오버뷰 다이어그램, 타이밍 다이어그램
순서 다이어그램 : 객체의 메시지 호출을 울타리 형태로 표현
커뮤니케이션 다이어그램 : 객체의 메시지 호출을 네트워크 형태로 표현
인터랙션 오버뷰 다이어그램 : 순서 다이어그램과 액티비티 다이어그램을 합성하여 그리는 형태로 표현
타이밍 다이어그램 : 시간의 흐름에 따른 구성요소의 상호작용과 상태변화를 그리는 형태로 표현
UML2.0 다이어그램

모델 다이어그램 설명 기능적 모델 사용 사례 다이어그램 액터와 사용 사례를 이용하여 시스템의 기능을 모델링 정적 모델 클래스 다이어그램 객체지향 시스템의 가장 근간이 되는 다이어그램으로 시스템의 정적인 구조를 나타냄 객체 다이어그램 클래스 다이어그램에서 생성된 객체를 나타내며 실행되는 동안의 객체들의 관계를 나타냄 패키지 다이어그램 관련된 클래스를 패키지로 그룹핑 하여 의존도를 낮추기 위하여 사용 컴포지트 다이어그램 연결된 컴포넌트의 구조를 표현 컴포넌트 사이의 커넥션(포트)을 나타냄 배치 다이어그램 노드, 컴포넌트, 커넥터 등 시스템의 물리적 자원 배치를 나타냄 컴포넌트 다이어그램 소프트웨어 부품, 예를들면 원시코드, 런 타임 라이브러리, 실행 파일 등의 구성을 나타냄 동적 모델 상태 다이어그램 외부 자극에 대한 시스템의 동적 상태 변화를 나타냄 외부 이벤트에 대하여 민감하게 상태를 변화 시키는 객체를 모델링 인터랙션 다이어그램 순서 다이어그램 클래스 사이의 메시지 교환을 시간이 흐름에 따라 나타냄 커뮤니케이션 다이어그램 순차 다이어그램과 같은 내용을 나타내지만 모양이 네트워크 형태 인터랙션 오버뷰 다이어그램 메시지 교환과 제어흐름을 동시에 표시 순서 다이어그램과 액티비티 다이어그램의 합성 타이밍 다이어그램 시간 제약이 중요한 실시간 시스템의 설계에 사용 시간의 흐름에 따른 구성요소의 상태 변화, 상호작용을 표현 액티비티 다이어그램 액티비티 단계별로 제어하는 흐름을 모델링하여 시스템의 동적 특징을 나타냄

Ⅰ. 시스템 기능에 대한 사용자 입장의 표현, 유즈케이스 다이어그램의 개요 가. 유즈케이스 다이어그램(Use Case Diagram)의 정의 - 시스템이 제공는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 다이어그램 - 시스템 분석가와 사용자가 시스템의 사용 방법과 목적을 결정하는데 도움을 주는 도구 - 시스템의 요구사항 중에서 기능적인 개별 요구사항을 표현 나. USECASE 다이어그램의 특징 1) 사용자의 기능적 요구사항을 정의하는 직관적인 표현 2) Use Case와 Actor간의 관계를 표현 (Actor는 시스템을 제외한 모든 외부요소로서 시스템을 사용하는 사람 또는 시스템이며, Actor는 Use Case를 수행함) 3) 주로 분석단계에서 수행하여 시스템 개발 전 단계에 영향 4) 시스템이 제공하는 기본적인 기능을 설명 5) 사용자와 대화 수단 활용 및 내부 기능을 예측할 목적임. II. Use Case의 구성요소와 구성요소간 관계 가. Use Case의 구성요소

구성요소 내용 표기법 Use Case 시스템이 제공해야 하는 서비스. Actor가 시스템을 통한 일련의 행위

Actor(행위자) - 사용자가 시스템에 대해 수행하는 역할(role) - 시스템과 상호작용하는 사람 또는 사물

시스템 (System) - 전체시스템의 영역을 표현 - 특별한 의미를 가지지 못함

나. Use Case의 구성요소간 관계

관계 설명 표기법 연관(Association) Use Case와 Actor의 관계를 표현(실선)

확장(Extend) 기본 Use Case 수행 시 특별한 조건을 만족할 때 수행하는 Use Case

포함(Include) 시스템의 기능이 별도의 기능을 포함(점선)

일반화 (Generalization) 하위 Use Case/Actor가 상위Use Case/Actor에게 기능/역할을 상속 받음

그룹화 (Grouping) 여러개의 Use Case를 단순화 하는 방법

다. Use Case 모델링 사례

레스토랑 상황을 고객, 웨이터, 요리사, 계산대 직원을 USECASE Diagram 으로 표현
Use Case 다이어그램 적용시 고려사항 가. 시스템 분석단계에서 의뢰인과 인터뷰로 사용자 도메인 이해 및 기능 요구사항과 시스템 요구사항을 구체화 나. 전체System이나 일부 System 문맥에서 행동을 파악하는데 중요한 Use Case만을 표현 다. 해당 부분을 이해하는데 필수적인 Use Case와 Actor만을 포함 관계는 너무 많이 표현하지 않고 반드시 필요한 것만을 표현

정적 모델링의 대표적인 표현 클래스 다이어그램
객체, 클래스, 속성, 오퍼레이션 및 연관관계를 이용하여 시스템을 나타냄
시스템의 구조를 나타냄
클래스 : 객체들의 공통 구조와 동작들을 추상화시킨 것
객체 : 시스템이 수행되는 동안 생성되고 변경되며 소멸될 클래스의 인스턴스
소프트웨어 엔지니어는 분석 단계에 응용 도메인의 지식을 정리하기 위하여 클래스 다이어그램을 작성
자세한 인터페이스나 네트워크 통신, 데이터베이스 저장 등은 표시하지 않음
시스템의 가장 기본적인 구성요소와 구조적 관계를 발견
클래스, 속성, 오퍼레이션 표현
박스를 세 개의 부분으로 나누고 맨위에는 클래스의 이름, 중간에는 클래스의 속성, 맨 아래 부분은 오퍼레이션
속성과 오퍼레이션의 이름 앞에 표시한 +, -, # 기호는 클래스의 외부 투명성(visibility)을 나타내기 위한 심볼
+는 public으로 선언되어 외부에서 접근 가능한 요소
-는 private로 선언되어 외부에서 사용이 불가능
은 protected로 선언되어 상속된 클래스에서만 제한적으로 사용
인스턴스가 없는 추상 클래스나 구현이 없는 추상 오퍼레이션은 {abstract}라고 표시
클래스의 유형을 의미하는 스테레오 타입 표시도 가능
클래스 사이의 관계 표현 가. 관계 종류
연관 관계 : 클래스의 인스턴스가 다른 클래스의 인스턴스로 메시지를 전달하는 관계
집합 관계 : 전체 개념의 클래스가 부분 개념의 클래스를 포함하고 있는 관계
복합 관계 : 전체 개념의 클래스가 부분 개념의 클래스를 포함하고 있는 관계(부모없이 자식은 존재할 수 없음)
의존관계 : 두 사물간의 의미적인 관계로써 한쪽(독립) 사물의 변화가 다른(종속) 사물에 영향을 주는 관계
상속 관계 : 일반적인 클래스의 정의를 구체화 된 클래스가 상속받아 사용하는 개념 나. 연관 관계(Association)
연관 관계를 표시한 선의 끝에는 역할(role)을 표시
Inventory와 video 클래스 사이의 연관 관계에 표시된 has와 exit가 역할
역할을 표시하는 이유는 연관 관계가 어떤 클래스로부터 연유된 것인지 나타내기 위함
역할의 표시로 관계의 목적을 더 분명히 할 수 있음
연관 관계의 끝에는 숫자가 표시되어 있는 경우 클래스의 인스턴스에서 연관된 링크의 개수를 의미
역할 위에 쓴 숫자가 다중도(multiplicity)
- 은 다중도를 표시한 것이며 다수라는 것을 의미
양방향

class A {
private B b }
class B {
private A a }

=> 서로에 대한 참조 멤버변수를 갖음 - 단방향

class A { private B instance[16]; }
class B {}

=> A가 B객체의 instance라는 이름의 참조 멤버변수 16개를 갖음 => 16대신 *일 경우 verctor나 list를 의미할 수 있음 - 재귀(Recusive Association)

class A { private A a; }

=> 자기 자신을 참조할수 있는 경우 - Inner Class(내부 클래스)

Class A { Class B {} }

=> 클래스 안의 클래스 - Association Class(연관 클래스)

class A { private Vector instance; }

=> A 는 B 를 Vector 에 담아 표현함을 나타낸다. => Association Class 보단 아래처럼 스테레오 타입의 사용이 더 낫다.

Association Qualifier (연관 한정사)

class A { private int id; public string getName() { B b = DB.getB(id); return e.getName(); } } class B {}

=> A 는 B 에 id 를 통해 접근함을 표현, 키나 토큰을 통해 연관을 나타낼때 사용 - Realization (실체화 : 구현)

class A {} class B : public A {} //Java 는 implement A

=> B 가 A 인터페이스를 구현 다. 집합관계(Aggregation) - Directory가 여러 File들로 구성된 것과 같은 관계 - 대부분이 일대 다의 관계 - Whole(전체)-Part(부분) 관계, 하지만 Whole(전체)과 Part(부분)의 생명주기가 일치할 필요 없음 - 전체 부분 관계는 전체 개념의 클래스에 다이아몬드 표시 - 예

class A { private Vector vectorB } class B {}=> A가 B의 집합을 가지나 생명주기는 이질적인 경우에 사용(A가 소멸한다고 해서 B가 소멸하지는 않음) => UML2.0에서 제외됨(Association(연관)와 차이 없음) 라. 복합관계(composition) - Whole(전체)–Part(부분) 관계, Whole(전체)과 Part(부분)의 생명주기가 같음 - 집합관계와 복합관계의 차이점

소스코드 예

Class Car { Car() { new Engine, Tire, Handle
} ~Car() { delete Engine, Tire, Handle } }

A가 B의 집합을 갖고 생명주기도 동일(A 소멸 시 B소멸. A, B가 항상 같이 소멸)

class A { private Vector vectorB } class B {}마. 의존관계(dependency) - 요구(Client)와 제공(Sever)의 관계, 단방향성 only - (Use 관계)

소스코드 예

Class System { displayForm(class Form) { ................. } }

class A { void method(B b) { } }
class B {}

바. 상속 관계 - 일반화된 개념의 클래스와 더 구체적인 개념의 클래스 사이의 관계 - 서브 클래스는 부모 클래스로부터 속성과 오퍼레이션을 상속 받음

소스코드 예

class Adult::Customer{ ........................ }

class A {} class B : public A {}
//Java는 extends A

=> B가 A를 상속 사. 클래스 다이어그램 관계 기법

관계 설명 표기법 연관관계 (Association) 두 클래스간 서로 어떠한 연관을 가지고 있음

한 클래스가 다른 한 클래스의 참조를 유지하는 관계 집합관계 (Aggregation) 클래스와 클래스간 부분과 전체의 관계를 의미

연관 관계 중 두 클래스의 생명주기가 다른 관계 복합관계 (Composition) 연관 관계 중 두 클래스의 생명주기가 같은 관계

의존관계 (Dependency) 한 클래스가 다른 한 클래스의 참조를 유지하지 않는 관계

상속관계 (Inheritance) 한 클래스가 상위 클래스 또는 인터페이스를 상속하고 있는 관계

접근지정자 멤버 변수 및 메서드의 접근 영역을 의미 + : public - : private

: protected

public : 외부에서 접근 가능 private : 내부에서만 접근가능 protected : 동일 패키지 및 하위 클래스 접근가능

마. 코드 변환 예

클래스의 의존관계(Dependency Relationship) 구현방법 가. 클래스간의 의존관계 표현방식
클래스가 변경되었을 때 이것을 사용하고 있는 다른 클래스에 미치는 영향으로 아래의 3가지 방법으로 구현 1) 한 클래스의 메소드가 다른 클래스의 객체를 인자로 받아 메소드를 사용 2) 한 클래스의 메소드 내부에서 다른 클래스의 객체를 생성하여 그 메소드를 사용 3) 다른 클래스의 메소드가 또 다른 클래스의 객체를 반환함. 이때 이 메소드를 호출하여 반환되는 객체의 메소드를 사용 나. 소스코드 의존관계 구현사례

1) 매개변수를 사용한 의존성 표현 Class ClassA ` Public void methodA(Class B param) { // 매개변수로 ClassB를 이용 …. ; D Class ClassB { // ClassB 선언 } 2) 클래스 생성을 통한 의존성 표현 Class ClassA { Public void methodA() { // 내부에서 ClassB를 호출 ClassB b = new ClassB(); …. } } Class ClassB { // ClassB 선언 }

실무측면에서의 클래스 관계적용을 위한 고려사항
일반적으로 개념모델의 분석단계에서는 객체간의 관계가 불명확해서 모두 Association으로 연결하다가 점점 상세화하면서 Aggregation이나 Composition으로 변경
반복적인 검토활동을 통하여 5가지의 클래스 관계에 대한 정확한 이해를 통하여 구체적인 관계를 확정하는 것이 중요하며, 설계자 입장에서도 이러한 관계를 정확히 작성하는 것이 개발자에게 설계자의 의도를 정확히 전달하고, 설계자의 입장에서 구현에 미치는 영향을 예측하는데 도움을 줄 수 있음

클래스 찾기 가. 정적 모델링 : 사용 사례를 작성하여 도메인 분석이 어느 정도 된 후에는 객체를 찾고 관계를 정의하는 작업으로 진입 나. 클래스 후보들
엔티티 클래스(entity class)
경계 클래스(boundary class)
제어 클래스(control class) 다. 엔티티 클래스
시스템에서 영구적으로 저장되어 사용될 자료를 보관하는 역할을 하는 클래스
시스템에서 계속 추적해할 자료가 들어 있는 클래스
실세계에 존재하는 개체들은 대부분 엔티티 클래스
엔티티 클래스 발견하는 방법 => 사용 사례를 이해하기 위하여 사용자와 개발자가 명확히 규정한 용어 => 사용 사례에서 반복되어 나오는 용어 => 시스템이 계속 추적하여야 하는 실세계의 엔티티 => 자료 저장소 또는 단말 => 자주 사용하는 응용 도메인의 용어 라. 경계 클래스
시스템 외부의 액터와 상호 작용하는 클래스로 인터페이스를 제어하는 역할
액터와 연결된 시스템 인터페이스
사용 사례에서 액터는 적어도 하나의 경계 클래스와 대화
액터로부터 정보를 수집하여 엔티티 객체나 제어객체가 사용할 수 있도록 형태를 바꿈
사용자 인터페이스를 개괄적으로 모형화한 것
사용자가 자료를 시스템에 입력하기 위하여 필요한 양식과 윈도우를 찾음
시스템이 사용자에게 반응하는 메시지나 알림을 찾음
인터페이스가 시각적으로 어떻게 보이는지는 경계 객체에 모형화 하지 않음
인터페이스를 나타내는 사용자 언어는 구현 기술과 관련 없는 용어를 사용 마. 제어 클래스
경계 클래스와 엔티티 클래스 사이에 중간 역할
경계 클래스로부터 정보를 받아 엔티티 클래스에게 전달해 줌
비즈니스 로직을 담고 있는 클래스
예 : 양식의 순서, undo, 히스토리 저장 큐, 분산 시스템에서의 정보 전달
연관 관계 찾기 가. 순서 다이어그램 : 시간이 흐름에 따라 진행되는 객체 사이의 상호작용을 나타냄 나. 클래스 다이어그램 : 객체 사이의 공간적인 연결 다. 연관 관계 : 두 개 이상의 클래스 사이에 어떤 관계가 있음을 나타냄 라. 예1
Rental 클래스는 Customer 클래스와 VideoTape 클래스와 밀접한 관계
Rental 클래스에는 어떤 고객이 어떤 테이프를 언제부터 얼마 간 대여하였는지 기록

마. 예2 - 비디오를 대여할 때 대여를 관리하는 사용자 인터페이스 화면에 대여하려는 테이프가 디스플레이

바. 연관 관계 속성 - 이름 : 두 클래스 사이의 연관 관계를 나타냄, 연관 관계의 이름은 생략 가능 - 역할 : 연관 관계의 양쪽 끝에 있는 클래스의 기능을 나타냄 - 다중도 : 연관 관계를 구성하는 인스턴스의 개수(예 : *는 RentUI가 0 또는 다수의 VideoTape을 화면에 디스플레이 할 수 있음) 6. 속성 찾기 가. 속성 : 개별 객체들이 가지는 특성 나. 예 : Receipt에서 나타낸것 처럼 영수증 발급 일시(Date), 고정으로 찍히는 부분(Title), 금액(Total) 등의 속성

Receipt - Date : date - Title : string - Total : float

다. 속성 요소 - 이름 : 객체 안에서 구별할 수 있는 속성의 이름(예 : Date, Title, Total) - 간단한 설명 : 구현하는 프로그램을 위하여 간단한 설명을 첨가 - 속성값의 타입 : 예를 들어 date, string, float 값

패키지 다이어그램
클래스를 의미 있는 관련된 그룹으로 구성하는 메커니즘
클래스를 논리적으로 그룹핑하는 것으로 java 프로그래밍 언어의 Package 선언으로 매핑
최상위층에는 구조적인 개체들(사용자 인터페이스, 비즈니스 도메인, 서브 시스템과 관련된 패키지)
하위층에는 더 작은 개념의 비즈니스 작업
소프트웨어 구조를 표현하는데 적합
패키지가 클래스의 그룹 이름으로 높은 수준의 추상화된 서브시스템을 표현
표현 방법
두 서브시스템 사이의 의존관계 나타냄
myGUI가 java.awt에 포함된 내용을 사용하고 있다는 의미
패키지 다이어그램은 중첩이 가능
Clerk User Interface 패키지 안에 Business System Client 패키지, Customer 클래스, Rental UI 클래스가 정의 되어 하나의 서브시스템으로 구성
패키지 다이어그램 표기법과 사례 가. 패키지 다이어그램 표기법

구분 내용 패키지 - 내부에 다른 요소를 포함하는 요소로 네임스페이스 역할

패키지 임포트 관계 - 다른 패키지의 요소를 자신의 것처럼 사용하는 관계

패키지 머지 관계 - 패키지를 병합하여 새로운 패키지를 구성하는 관계

나. 패키지 다이어그램 사례

학생, 교수 및 수강 패키지의 관계를 패키지 다이어그램으로 표현
학생 및 교수 패키지는 수강 패키지를 임포트 관계로 사용하고, 수강패키지는 IT 및 경영 패키지로 구성됨

컴포지트 스트럭처 다이어그램 표기법과 사례 가. 컴포지트 스트럭처 다이어그램(Composite Structure Diagram) 표기법

구분 내용 파트 - 클래스나 인터페이스의 실행 인스턴스

포트 - 분류자와 분류자 외부 환경 또는 분류자의 내부 파트들 사이의 상호 연결점 커넥터 - 프로퍼티(파트) 간의 상호 작용을 선으로 표현

콜레보레이션 - 역할(Role)과 연결(Connector)의 집합 - 특정한 기능을 수행하기 위해 필요한 프로퍼티와 역할만을 정의함

나. 컴포지트 스트럭처 다이어그램 사례

자동체 내부의 프로퍼티(파트)간의 관계를 모델링
엔진 클래스의 인스턴스가 자동차 클래스의 프로퍼티가 되며, 외부 레퍼런스를 뜻하여 점선으로 표기
뒷바퀴는 2개를 의미하고 엔진과 연결됨 다. 컴포넌트의 내부 구조를 분해해서 설계

컴포넌트 다이어그램
시스템 내부에 어떠한 컴포넌트가 존재하는지를 알리고, 컴포넌트 간의 관계를 나타내는 다이어그램

[그림 5-8] 컴포넌트 다이어그램 [그림 5-8]에서 컴포넌트 하나와 인터페이스 둘을 볼 수 있다. 여기서 ‘Order’가 컴포넌트이며, ‘OrderEntry’는 ‘컴포넌트가 제공하는 오퍼레이션’º을 알리는 인터페이스—실체화 관계로 연결되어 있기 때문에—이고, ‘Person’은 ‘Order 컴포넌트가 사용하는 인터페이스’—의존 관계로 연결되어 있기 때문에—이다. [그림 5-9]은 컴포넌트들이 서로서로 의존하고 있는 관계를 다이어그램으로 나타낸 것이다

[그림 5-9] 컴포넌트 의존 관계를 나타내는 다이어그램 [그림 5-10]는 컴포넌트를 또 다른 형태로 표현한 다이어그램이다

[그림 5-10] 제공 인터페이스와 요구 인터페이스가 표현된 컴포넌트 다이어그램 Order 컴포넌트가 제공하는 오퍼레이션을 알리는 인터페이스는 ItemAllocation과 Tracking이며, 반원으로 표시된 Person과 Invoice 및 OrderableItem은 Order 컴포넌트에서 사용하는 인터페이스이다. 이렇게 컴포넌트가 제공하는 인터페이스는 원으로 표시하며, 컴포넌트가 사용하는 인터페이스는 반원으로 표시한다. [그림 5-11]는 컴포넌트를 클래스 형식으로 표현한 것이다.

[그림 5-11] 클래스 형식으로 표현한 컴포넌트 컴포넌트에서 구현하여 제공할 오퍼레이션과 컴포넌트에서 사용할 오퍼레이션을 ‘클래스의 오퍼레이션’형식으로 표현하고 있다. [그림 5-12]은 컴포넌트 내부 클래스를 함께 표현한 다이어그램이다

[그림 5-12] 내부를 표현한 컴포넌트 다이어그램 Order 컴포넌트 내부에 OrderHeader 클래스와 LineItem클래스가 존재하며, 그들이 서로 Composite Aggregation 관계로 연결됨을 나타내고 있다 [그림 5-13]은 컴포넌트 내부에 또 다른 컴포넌트가 표현된 사례이다

[그림 5-13] 컴포넌트 내부에 컴포넌트를 포함하는 컴포넌트 다이어그램 ‘Store 컴포넌트’내부에 Order 컴포넌트와 Customer 컴포넌트 및 Product 컴포넌트가 있음을 나타낸다. 각 컴포넌트에서 제공하는 오퍼레이션을 인터페이스로 알리고 있음을 볼 수 있다. 또한, Store 컴포넌트가 ‘외부에 제공하는 인터페이스(OrderEntry)’와 ‘사용할 필요가 있는 인터페이스(Account)’로도 표현되어 있다. 2. 컴포넌트 다이어그램 구성요소 가. 컴포넌트(Component) [그림 5-14]와 같이 ‘스테레오 타입이 있는 클래스 타입’으로 표시하거나, 아이콘 형태로 나타낸다

[그림 5-14] 컴포넌트 나. 제공 인터페이스(Provided Interface) 컴포넌트가 제공하는 오퍼레이션을 알리는 역할을 한다. 이러한 인터페이스를 컴포넌트가 실체화하고 있다. [그림 5-15]와 같이 작은 동그라미를 컴포넌트와 연결하여 표현한다

[그림 5-15] 제공 인터페이스 다. 요구 인터페이스(Required Interface) 컴포넌트가 의존하고 있는 인터페이스를 나타내기 위해 사용한다. [그림 5-16]처럼 반원을 사용하여 표현한다

[그림 5-16] 요구 인터페이스 라. 포트(Port) 컴포넌트 외곽에 작은 사각형으로 표현하며, ‘제공 인터페이스(Provided Interface)’나 ‘요구 인터페이스(Required Interface)’를 표현할 수 있다

[그림 5-17] 포트 마. 조립 커넥터(Assembly Connector) [그림 5-82]과 같이 ‘볼 소켓(Ball and Socket)’형태로 표시하며, ‘제공 인터페이스(Provided Interface)’와 ‘요구 인터페이스(Required Interface)’의 연결을 의미한다

[그림 5-18] 조립 커넥터

동적 모델링 가. 정의
클래스를 발견하고 난 후에는 클래스들의 상호작용이나 클래스의 상태 변화 등 시스템 내부의 동작에 관심을 기울임 나. 다이어그램 종류
인터랙션 다이어그램 : 사용 사례를 실현시키기 위하여 내부 클래스들이 어떻게 협동하는지 나타내는 다이어그램 => 순서 다이어그램(sequence diagram) : 객체를 울타리 형태로 나열하고 이벤트의 순서를 위에서 아래로 명시하는 타입 => 커뮤니케이션 다이어그램(communication diagram) : 클래스를 네트워크 형태로 배치하고 메시지 교환 순서를 숫자로 표시하는 방법
상태 다이어그램 : 복잡한 객체의 상태 변화를 나타냄, 이벤트의 발생에 의하여 객체가 어떤 식으로 변화해 나가는지를 나타냄
액티비티 다이어그램 : 절차나 작업의 흐름을 나타냄, 작업이 순차적인지 병렬 가능한 것인지 또는 어떤 작업과 동기화 되어야 하는지를 나타냄
인터랙션 다이어그램 가. 정의
객체 사이의 동작을 분산시키고 오퍼레이션을 찾아내는데 사용
단일 사용 사례에 대한 시스템의 동작을 나타냄 나. 종류

다이어그램 설명 순서 다이어그램 시스템의 동작을 정형화하고 객체들의 메시지 교환을 울타리 형태로 시각화하여 나타냄 사용 사례 다이어그램에 관련된 객체를 추가로 찾아내는데 유용함 이를 참여 객체(participating object)라고 함 객체 사이에 일어나는 상호 작용 맨 왼쪽 열은 사용 사례를 동작시킨 액터를 나타냄 설명이 붙은 화살표는 액터나 객체가 다른 객체에게 보낸 메시지를 나타냄 객체들 사이의 상호 작용을 위한 통신패턴을 나타냄 커뮤니케이션 다이어그램 위임과 전달의 관계를 네트워크 형태로 더 명확히 보여줌

- 간단한 순차적인 제어흐름을 표시하기에는 순서 다이어그램이 좋지만 반복이나 분기와 같이 여러 객체 사이에 일어나는 복잡한 상호작용은 커뮤니케이션 다이어그램으로 표시

Ⅰ. 시간의 흐름에 따라 표현하는 시퀸스 다이어그램(Sequence Diagram) 가. 시퀸스 다이어그램(Sequence Diagram)의 정의 - 인터랙션 다이어그램의 가장 일반적인 형태이며, 객체 간에 송·수신하는 메시지를 시간의 흐름에 따라 나열한 다이어그램 - 문제 해결에 필요한 객체를 정의하고 객체간 주고받는 메시지의 순서를 시간의 흐름에 따라 보여주는 다이어그램 - 클래스가 실행된 객체간의 상호작용을 표현 - 협동 다이어그램(Collaboration Diagram)과 인터랙션(Interaction)측면에서 같은 정보를 담고 있는 다이어그램 나. 시퀸스 다이어그램의 특징 1) Use Case 시나리오를 시간과 순서에 따라서 묘사 및 도식화 2) 객체간 동적 상호작용을 시간적 개념을 중시하여 모델링 3) 객체의 오페레이션과 속성을 상세히 정의 4) 프로그래밍 사양 정의 5) 여러개의 객체들 사이의 동적인 협력사항 표현 6) 객체들 간의 관계성은 표현 안 함 7) 복잡한 시나리오나 실시간 명세 표현, 메시지의 명시적인 순서를 나타내기에 좋음 Ⅱ. 시퀸스 다이어그램의 구성요소 및 예시 가. 시퀸스 다이어그램의 구성요소

구성요소 내용 활성 객체 시스템의 행위자이거나 시스템 내의 유효한 객체 메시지(Message) 서로 다른 활성 객체간의 의사소통 제어사각형 (Control Rectangles) 객체가 제어를 가지고 있다는 것, 어떤 종류의 정보를 처리하고 있다는 것 또는 다른 정보를 기다리고 있다는 것을 표시

나. 시퀀스 다이어그램 구성요소 설명 1) 활성 객체 - 시스템의 행위자이거나 시스템 내의 유효한 객체 - 왼쪽에서 오른쪽으로 표현되며 객체는 생명선은 가지고 있음

2) 메시지 - 서로 다른 활성 객체간의 의사소통을 묘사하는데 이용 - 호출 활성화 객체이 생면선으로부터 비호출 객체의 생명선까지 화살표로 그리지며, 화살표 위에는 보내지는 메시지가 위치

3) 의사소통을 위한 메시지 사용 방법

종류 내 용 동기 (Synchronous) - 메시지가 완료될 때 비로소 흐름이 중단되며, 메시지로부터 전송된 임의의 메시지들이 전송 완료시 중단됨을 표시 - 동기 메시지는 안이 채워진 화살표와 실선으로 모형화 반환 (Return) - 제어흐름이 호출 활성화 객체로 반환됨을 보여주며, 동기 메시지가 그 임무를 완료했음을 표시 - 반환 메시지는 열려진 화살표와 점선으로 모형화 비동기 (Asynchronous) - 활성 객체가 응답을 기다리지 않고 전송되는 메시지에 사용 - 비동기 메시지는 반이 열린 화살표와 굵은 선으로 모형화 평판(Flat) - 동기와 비동기의 구분이 없음 - 평판 메시지는 열린 화살표와 굵은 선으로 모형화

4) 제어사각형(Control Rectangles) - 객체가 제어를 가지고 있다는 것과 어떤 종류의 정보를 처리하고 있다는 것과 또는 다른 정보를 기다리고 있다는 것을 표시하기 위해서 사용 - 순차 다이어그램에서 제어 사각형은 객체의 생명선(lifelne) 위에 속이 빈 사각형으로 표시

다. 작성순서 - 유즈케이스 다이어그램 정의 후부터 프로그램 코딩 전에 작성 - 수평선상에는 서로 다른 객체를 나타내고 수직선 상에는 시간이 지나가는 것에 따라서 객체들 사이에 메시지 교환을 나타냄 1) 작성대상 선정 : 유즈케이스를 선정하고 유즈케이스 정의서 분석 2) 액터 위치시킴 : 액터는 좌측부터 위치 3) 클래스 위치시킴 : 유즈케이스에 참여하는 클래스 위치 4) 객체간 메시지 정의 : 시간 순서대로 객체간 메시지 정의 5) 객체 추가정의 : 요구사항 처리를 위해 필요한 객체가 정의되지 않았으면 추가 라. 시퀸스 다이어그램의 예시 1) 고객 로그인 및 상품 주문 예시

고객이 시스템에 접속하여 상품을 주문하는 시퀸스 다이어그램 마. 시퀀스 다이어그램 작성 예제

III. 시퀸스 다이어그램 작성시 주의 사항 1) 동일한 상호작용을 여러 시퀸스 다이어그램에서 중복 작성에 주의 2) 중복을 최소화 시키기 위해 UI별 시퀸스 다이어그램을 작성 3) 가독성이 좋도록 코멘트(Commnet) 사용 4) 메시지의 흐름은 액터로부터 시작하도록 작성 5) 클래스 다이어그램에 표기된 클래스명과 매핑 가능하도록 객체 이름을 표기

상태 다이어그램
객체가 가질 수 있는 가능한 상태들과 그 변화를 나타낸것 여기서 상태는 객체가 갖는 특정 값을 의미
객체가 어떤 상태에서 다른 상태로 변하게 만드는 것은 이벤트
표현 방법

표현 내용 ● 시작 노드 ◉ 종료 노드 둥근 사각형 상태를 나타냄 화살표 상태 사이의 전환을 의미

조건은 화살표 위에 괄호 안에 기술 I. 스테이트(State Diagram) 다이어그램의 개요 가. 스테이트 다이어그램의 정의
클래스의 객체가 가질 수 있는 모든 가능한 상태를 보여주며, 특정 객체에 대하여 사전 발생에 따른 상태 천이과정을 묘사한 다이어그램
객체가 보유하는 상태와 상태가 전이하는 제어흐름을 표현
객체, 컴포넌트 또는 시스템을 대상으로 동적 행위를 상태(state)와 전이(transition)로 표현 나. 스테이트 다이어그램의 특징 1) 진입 조건, 탈출 조건, 상태 전이에 필요한 사건 등 자세한 사항이 기술 2) 설계 단계에서 클래스 객체의 동적인 행동 방식을 표현하는 데 사용 II. 스테이트 다이어그램의 예시
문서 작성 및 결재 업무에서 문서의 상태 및 천이 과정을 묘사한 스테이트 다이어그램 Ⅲ. 상태 다이어그램 작성 방법 순서 가. 상태 다이어그램으로 작성하고자 하는 범위를 파악 나. 표현하려는 대상의 시작, 종료 상태를 파악 다. 객체가 어떤 상태들을 갖는지 찾아냄 라. 상태 변환과 관련된 이벤트, 액션, 조건을 찾음 마. 상태 머신이 올바로 작성되었는지 검증

액티비티 다이어그램
시스템의 동적인 부분을 모델링 하는 목적으로 사용되며 액티비티 사이의 제어 흐름을 보여주는 일종의 흐름도
상호 작용을 보여주는 또 다른 방법으로 액션이 어떻게 이루어지며 무엇을 수행하고 언제 발생하며 어떤 액션과 동기화 또는 병렬 수행되는지를 나타냄
시스템을 액티비티로 표현
액티비티 : 오퍼레이션의 집합이 수행됨을 나타내는 상태 Ⅰ. 비즈니스 작업흐름을 표현하는 활동 다이어그램(Activity diagram)의 개요 가. Activity 다이어그램의 정의
객체의 상태가 아닌 처리 로직이나 조건에 따른 처리흐름을 순서에 따라 정의한 다이어그램
어떠한 행위에 따라 객체의 상태를 표기
시스템 내부에 존재하는 여러가지 행위들 그리고 각 행위의 분기, 분기되는 조건 나. Activity 다이어그램의 특징 1) 처리흐름의 도식화로 프로그램 로직 정의 가능 2) 비즈니스 프로세스 정의 : 업무의 As-is분석, To-be분석 가능 3) Use Case의 실현(Realization) II. Activity 다이어그램의 구성요소와 예시 가. Activity 다이어그램의 구성요소

구성요소 설명 표기법 Activity state/Activity(활동) 행위나 작업(내부적으로 구조를 가지는 단위)등 무언가를 하고 있는 상태

시작 상태(Initial State) 처리흐름이 시작되는 곳을 의미

종료 상태(Final State) 처리흐름이 종료되는 곳을 의미

선택점(Decision) 논리식의 결과에 따라 분기가 일어나는 곳

전이(Transition) - 하나의 상태에서 다른 상태로의 제어 흐름을 보여주는데 사용 - 상태에서 활동으로의, 또는 상태들 사이의 흐름을 보여줌

구획면(Swim lane) 업무조직이나 개인의 역할에 따른 처리구분 구분영역

나. Activity 다이어그램의 작성 순서

구분 설명 작성 대상 선정 업무프로세스 모델링, 오퍼레이션 사양 정의 Swim lane 정의 대상영역에 명확한 역할을 정의해야 할 때 처리절차 모델링 시작점, 끝점 반드시 표현

다. Activity Diagram 예시 1) 고객 로그인 및 상품 주문 예시

2) 전화 주문 시 재고 정보 조회 예시

3) 예

III. Activity 다이어그램의 효과 가. 사건 발생에 관련된 객체들의 상화관계를 일렬로 도식화 나. 순서적 흐름, 병행 프로세스를 지원으로 불필요한 순서를 없애기 위한 효과가 있음

디플로이먼트 다이어그램(Deployment Diagram)
전체 시스템을 구성하는 하드웨어와 하드웨어의 연결 관계를 표현하는 다이어그램
각 하드웨어와 하드웨어에 배치되는 아티팩트(시스템에 존재하는 소스 코드, 산출물과 같이 물리적으로 존재하는 정보)를 표현
시스템의 물리적인 부분의 구성을 나타냄.
디플로이먼트 다이어그램은 실제 하드웨어적인 배치와 연결상태.
컴포넌트 다이어그램은 소프트웨어의 물리적 단위(Exe, DLL 등 기타 library)의 구성과 연결상태를 표현
육면체로 표현된 기호는 하드웨어를 의미하며, 사각형 기호는 아티팩트
디플로이먼트 다이어그램 구서요소 가. 노드(node) 『UML User’s Guide 』에는 ‘J노드란 실행 시간에 존재하고 컴퓨터 자원(Computing Resource)을 나타내는 물리적인 요소이다. 일반적으로 노드는 컴포넌트가 배치되는 컴퓨터나 장치를 의미한다”J라고 정의되어 있다. 노드는 물리적인 요소이며, 시스템이 실행될 때 존재하며 어느 정도의 메모리와 처리 능력을 갖춘 전산 자원이다

[그림 5-21] 노드 노드는 [그림 5-21]처럼 육면체로 표현한다. 나. 아티팩트(Artifact) 아티팩트는 물리적인 형태의 모든 정보를 의미한다. 즉 모델 파일, 소스 코드, 산출물, 실행 파일 등등이 아티팩트이다. 아티팩트는 [그림 5-22]처럼 “<>’라는 스테레오 타입으로 표현한다

[그림 5-22] 아티펙트 다. 연관 관계 연관 관계를 의미한다. 디플로이먼트 다이어그램에서 연관 관계는 물리적인 연결을 의미한다.

[그림 5-23] 연관 관계 라. 의존 관계 의존하고 있는 관계를 의미한다. 디플로이먼트 다이어그램에서 의존 관계는 아티팩트와 아티팩트가 배치되는 노드 사이를 나타내기 위해 사용한다

[그림 5-24] 의존 관계

Timing Diagram 가. 교류 다이어그램의 또 다른 형태로 단일 객체 뿐 아니라 여러 개의 객체들에 대한 타이밍 제약 조건에 초점
여러 대상간의 상호작용을 시간에 따른 상태 변화의 형태로서 표현 나. 타이밍 다이어그램 표현법 – 가로선의 변화로 타이밍 변화를 나타내는 법 – 서로 선을 교차하는 방법으로 영역을 명시하여 타이밍 변화를 나타내는 법
Interaction Overview Diagram 가. 액티비티 다이어그램과 시퀀스 다이어그램을 접목한 다이어그램 나. 액티비티들이 작은 시퀀스로 분리되어 표현
Communication Diagram 가. 객체와 객체 사이에 메시지 호출 관계를 설계하는 다이어그램 나. 구성요소 – 객체간의 연결 관계를 강조 – Object – Link

※ 객체 다이어그램(Object Diagram) 가. 시스템에 있는 객체들의 어떤 순간의 모습을 가시화 나. 인스턴스 다이어그램 - 클래스가 아닌 인스턴스를 보여줌 다. 표기법 – 인스턴스명 : 클래스명 – 클래스 다이어그램의 구조를 좀더 정확하게 정의할 수 있음

클래스 재사용

프레임워크 가. 정의
객체지향에서 사용빈도가 높은것
설정에 맞도록 커스터마이징 할 수 있게 고안된 재사용 가능한 부분적인 응용 프로그램
대규모 정보시스템을 개발할 때 활용되는 개발∙실행∙테스트∙운영환경을 지원하는 소프트웨어
프레임워크를 도입하면 어느 정보시스템을 구축하더라도 공통적으로 개발해야 하는 영역을 미리 만들어 개발기간을 단축 시킴
표준화를 한만큼 개발생산성과 개발품질도 높일수 있음 나. 후크 메서드(hook Method)
응용 도메인의 인터페이스와 동작인 특수한 경우 약간의 차이를 체계적으로 분리
응용 프레임워크에서 재정의하여 확장성을 향상시킴
프레임워크 위치에 따른 분류 및 기술에 따른 분류 가. 프레임워크 위치에 따른 분류

프레임워크 내용 인프라 구조 프레임워크 소프트웨어 개발 프로세스를 간소화하기 위한 목적의 프레임워크 ex : 운영체제, 디버거, 통신 테스팅, 사용자 인터페이스 설계 미들웨어 프레임워크 분산된 응용 시스템과 컴포넌트를 통합하는데 사용 ex : MFC, DCOM, Java RMI, CORBA, 트랜잭션 데이터베이스 엔터프라이즈 응용 프레임워크 통신, 항공기, 환경, 제조, 금융, 기업 비즈니스 액티비티와 같은 도메인에 유용

인프라 구조 및 미들웨어 프레임워크는 높음 품질의 소프트웨어 시스템을 빨리 만들기 위하여 긴요하지만 외부 사용자들에게 필요하지는 않음
인프라 구조 및 미들웨어 프레임워크는 직접 만드는 것보다 구입하는 것이 더 효율적
엔터프라이즈 응용 프레임워크는 엔드유저용 응용 시스템의 개발을 지원 나. 프레임워크 기술에 따른 분류

프레임워크 내용 화이트박스 프레임워크 확장을 위하여 상속 개념과 동적 바인딩을 이용 프레임워크 기본 클래스의 서브 클래스를 정의하고 템플릿 메서드 패턴과 같은 것을 이용하여 미리 정의된 후크 메서드를 재정의함으로 현재 기능을 확장 프레임워크 내부 구조에 대한 사전 지식이 필요 상속 구조와 밀접하게 의존되어 프레임워크에 대한 변경이 있을때 응용 시스템을 다시 컴파일 함 블랙박스 프레임워크 프레임워크에 컴포넌트를 플러그인할 있도록 인터페이스를 정의하여 확장하는 방식 프레임워크에 위임 방법 이용하여 통합함으로써 재사용 상속보다는 위임을 사용하기 때문에 사용하기가 쉬움 인터페이스와 후크를 정의하여 하기 때문에 개발하기는 어려움

표준화를 통한 상호운영성 확보 및 중소SW 기업 참여확대를 보장하는, 전자정부 프레임워크 가. 정의
실행, 개발, 4개의 환경과 13개의 서비스 그룹 등으로 구성된 전자정부 구현을 위한 표준 프레임워크
정보시스템의 효율적 개발과 유지보수 용이성 확보를 위하여 표준화한 개발지원 도구 나. 등장 배경
각 사업별로 공통컴포넌트 중복 개발
기관별/사업별 개별적인 정보화 사업추진
최적화/표준화된 공통개발기반 요구
특정업체 종속성 발생으로 인한 공정경쟁 저하 및 사업자 변경시 예산낭비
개발표준 부재로 시스템간 상호운영성 및 재사용성 저하 다. 전자정부 프레임워크와 민간 프레임워크 장단점 비교

전자정부 프레임워크 구분 민간 프레임워크 특정제품이나 기술에 종속되지 않음 전자정부 표준 프레임으로 상호운용성 확보 무료 라이센스에 기술교육 지원 장점 다양한 고급 기능 제공 금융, 서비스 등 특화된 영역의 기능 제공 기본적인 기능만 제공 고급 기능이 제공되지 않음 단점 특정 제품이나 기술에 종속될 우려 높음 가격이 비싸고 특정 인력만 운용 가능

전자정부 표준 프레임워크 구성 및 적용 방안 가. 전자정부 표준 프레임워크 구성

환경 분류 내용 실행환경 Presentation(화면) Layer 업무 프로그램과 사용자 간의 Interface를 담당 MVC(Model-View-Controller), Spring MVC, AJAX Tags Business Logic (비즈니스) Layer 업무 프로그램의 업무 로직을 담당 업무 흐름 제어, 트랜잭션 관리, 에러 처리 등의 기능 제공 Spring WebFlow Persistence(데이터) Layer 업무 프로그램에서 사용하는 데이터에 대한 CRUD 기능을 제공 ORM(iBatis, Hibernate) Integration(연계) Layer 타 시스템과의 연동 기능을 제공하는 Layer Apache CXF Foundation(공통) Layer 실행 환경의 각 Layer에서 공통적으로 사용하는 공통 기능을 제공 DI (Dependency Injection), AOP(Aspect Oriented Programming) 개발환경 구현도구 업무 프로그램 구현을 지원하는 도구(eclipse 외) 테스트도구 구현된 업무 프로그램의 테스트를 지원 도구(Junit 외) 배포도구 구현 완료된 애플리케이션을 패키징하고 실행환경에 배포(Maven) 형상/변경관리도구 형상 및 변경관리 지원도구(subversion 등) 관리환경 개발관리도구 개발 지원을 위한 주요 환경설정 및 구성정보 변경 지원 운영관리도구 운영 지원을 위한 주요 환경설정 및 구성정보 변경 지원 운영환경 모니터링 도구 애플리케이션 상태등을 실시간으로 모니터링 하기 위한 도구 관리도구 사용자, 권한 등의 프레임워크 전반의 관리도구

나. 전자정부 표준적용 방안

구축 분류 내용 신규구축 적용형태 신규 구축과 같은 형태이며 이슈 없음 기존 시스템(Legacy) 교체 적용성 기존 시스템의 소스코드 수정 필요 연계구축 적용형태 별도의 신규 시스템을 구축하고 솔루션을 활용하여 연계 운영되는 형태 EAI/ESB(연계솔루션) 적용성 프레임워크 자체 이슈 없음, 단 연계를 위한 비용 발생 병행구축 적용형태 하나의 시스템에서 이기종 프레임워크가 듀얼 운영되거나 프레임워크가 없는 기존 코드가 병행 적용성 시스템 운영 및 개발성 문제 발생 가능성이 많은 Case별로 검토 필요

전자정부 표준 프레임워크 적용 절차 및 프레임워크 적용전 비교 가. 표준 프레임워크 적용 절차

절차 내용 도입검토 표준 프레임워크가 요구하는 시스템 요건 검토 JVM(Java Virtual Machine)을 설치하고 운용할 수 있는 서버 플랫폼 J2EE, JDBC 스펙을 준수한 WAS 및 DBMS에 대한 제약은 없음 JDK1.5 이상에 최적화되어 있으며, .NET환경에는 적용불가 자바기반 웹 애플리케이션 구축 사업에 원칙적으로 적용 가능 사업계획수립 표준 프레임워크 도입에 대한 사업계획수립 표준 프레임워크 개념에 대한 이해 재사용 가능한 공통컴포넌트를 선정하고 소요예산을 조정 표준 프레임워크 경험 인력 확보 방안 수립 사업수행 설계 표준 프레임워크 적용전략 수립 도입되는 H/W, S/W등 의 목표 아키텍처 설계 POC(Proof Of Concept)등을 통한 목표 아키텍처 검증 표준 프레임워크 실행환경 기반의 UML설계 개발자 및 SW아키텍트 대상 표준 프레임워크 정규 교육 수강 사업수행 개발 표준 프레임워크 적용 및 프레임워크 기반 개발 WAS, DB, 형상관리 등 구축환경 설정 표준 프레임워크 실행환경, 개발환경 및 환경 설정 프레임워크 템플릿 커스터마이징(UI 툴과의 연동 템플릿 작성) 표준 프레임워크 아키텍처 및 개발가이드(개발표준 포함) 수립

나. 전자정부 표준 프레임워크 적용 전/후 비교

구분 내용 프레임워크 적용 전 사업자별 동일한 기능 중복 개발 기술 종속으로 인해 선행 사업자 의존도 높음 프레임워크 미 보유업체는 경쟁 불리 상호 연계시 많은 기간과 인력이 소요 개발 표준 미흡으로 유지보수가 어려움 프레임워크 적용 후 공통컴포넌트 재사용으로 중복 예산 절감 표준화된 개발기반으로 사업자 종속성 해소 프레임워크 무상제공으로 중소기업 경쟁력 향상 표준화된 연계모듈 활용으로 상호운영성 향상 개발표준에 의한 모듈화로 유지보수가 용이

전자정부 표준 프레임워크 고려사항 및 기대효과 가. 고려사항

고려사항 내용 프레임워크 개발 타당성 프레임워크를 개발할지 표준 프레임워크를 재사용할지에 대해 충분한 검토 필요 프레임워크를 알자 프레임워크 자체에 대한 충분한 투자 및 이해 없이 100% 활용은 불가능 변화대응 능력 프레임워크가 기술 및 환경의 변화에 따라 얼마나 독립적인지 충분한 검토 필요 프레임워크 도입전략 마련 전략적 측면에서의 교육, PoC 등 다양한 방안으로의 도입전략 마련 요구 프로덕트 라인 기반 기본 프레임워크위에 도메인 프레임워크와의 결합을 통한 SW 생산성 향상

나. 기대효과

기대효과 내용 재사용성 강화 정부 부처가 공통컴포넌트 도출 및 SRM과의 연계를 통한 재사용성 강화 중소기업 참여 확대 대형 SI 사업자에 의해 좌지우지 되는 개발 프로젝트 지양하고 중소업체 참여 유도 프레임워크 표준화 OSS 기반의 표준 프레임워크 기반으로 구성하여 국제적인 표준화에 기여 상호운영성 확보 표준화된 프레임워크기반 개발을 통해 애플리케이션간 상호운영성 확보

공통 컴포넌트 가. 원칙
중복 개발의 빈도, 재사용성, 표준화 적용성이 높은 기능 나. 정의
정보시스템 구축시 여러 행정 기관이 공통적으로 활용하기 위하여 재사용이 가능하도록 기능위주로 개발한 소프트웨어
공통 컴포넌트 구성 가. 공통기술서비스
전자정부 표준 프레임워크기반에서 동작하는 공통컴포넌트

종류 내용 보안 실명확인, 권한관리, 암호화/복호화 등 8종 사용자 디렉토리/통합인증 일반로그인, 인증서 로그인, 로그인정책관리 3종 사용자 지원 사용자 관리, 상담관리, 설문관리, FAQ, Q&A 등 56종 협업 게시판, 동호회 관리, 커뮤니티 관리, 주소록관리 등 28종 시스템 관리 공통코드, 메뉴관리, 로그관리, 기관코드 수신등 25종 시스템/서비스 연계 연계현황관리, 연계기관 관리 등 4종 통계/리포팅 게시물통계, 접속통계, 보고서 통계 등 5종

나. 요소기술서비스 - 전자정부 표준 프레임워크와 상관없이 일반 자바환경에서 동작하는 공통컴포넌트 3. 공통 컴포넌트 기대효과 - 표준 프레임워크 템플릿 프로그램을 통해 개발자는 오직 비즈니스 로직 개발에만 전념하여 개발 생산성이 향상되고, 템플릿 기반의 개발 표준화를 통한 품질 보장 및 위험요소 극소화

객체의 테이블 매핑

객체지향 요소 관계형 데이터베이스 클래스 테이블 속성 테이블 속성(열) 기본키 기본키 반복되는 속성 별도의 테이블 연관 기본키-외부키의 쌍 다중도 외부키 집합관계 연관으로 변경 후 외부키 상속 서브 클래스를 별도의 테이블로 하여 미상속 속성만 매핑

SW 분리‧분할 발주

SW산업 활성화 방안 소프트웨어 분리발주 가. 소프트웨어 분리발주의 개념
SW사업 발주 시에 HW구매, SW구매, 시스템 개발 등의 일괄발주하는 형태에서 SW만을 별도로 분리하여 발주하고 평가∙선정, 계약, 사업관리 등을 실시하는 제도 나. 소프트웨어 분리발주 제도의 등장 배경
계약형태가 IT서비스 기업들이 SW제품 선택권과 가격 결정권을 가져 SW제품이 제값을 받기 어려움
SW 기업에 독자적인 입찰기회를 통한 품질위주의 경쟁 촉진 다. 필요성
SW 사업 추진 시에 기획 단계부터 철저한 시스템 분석과 이를 통한 우수 SW의 선정 등 정보시스템의 품질향상과 SW기업의 경쟁력 제고
상용SW기업이 주계약자로 참여하여 기업 간에 품질위주의 경쟁 촉진 및 일괄발주시 발생되는 하도급 폐해를 사전에 방지
소프트웨어 분리발주의 장애요소 및 극복방안 가. 소프트웨어 분리발주의 장애요소

관점 장애요소 극복방안 발주자 발주자 업무증가 분리발자 가이드라인 교육 지원 등 대폭적인 업무 지원 SW업체와 시스템 개발업체가 달라 시스템 통합의 어려움 시스템 통합ㆍ연계비용을 예산에 책정하도록 유도해 시스템 통합에 따른 분쟁소지를 최소화 제공자 하자책임 및 유지보수 분쟁 소지 발주기관에서 제안요청서에 분리발주 대상 SW의 기능을 구체적으로 명시해 책임한계를 명확하게 함 SW임치제, SW 개발 실명제 장착방안 모색

나. 소프트웨어 분리발주 장애요소의 기술적 극복방안

관점 기술적 극복방안 제도적 SW품질 인증제도 연계 비용 산정 FP, LOC 원가산정 기준 마련 객관적 자료 프로세스 Best Practice 모색 산업영역 분리 SI와 솔루션 업체 업무 영역 세분화

소프트웨어 분리발주의 현황 및 전망
정부는 현재 정보화 사업에서 분리발주 적용률은 약 21%이나 오는 2012년까지 70%까지 높이고, 해당 SW품목도 50종 이상으로 확대할 계획임
지방자치단체가 분리발주를 준수하도록 하기 위해 지방계약법 시행규칙을 개정해 내년부터 분리발주를 의무화하기로 함
공공기관에서 발주 제안요청서 작성 시 분리발주 대상 SW에 대한 기능과 규격을 구체적으로 명시하도록 했고, 우수 SW 도입을 위해 기술평가 비중을 현행 80%에서 90%로 높이도록 함 ※ SW분리발주는 매출 증대보다 대형 SI업체를 벗어나 공공사업이 가능해졌다는데 의의가 크다
SW분리발주의 예외사항 3가지 가. 통합불가/현저한 비용 상승
SW제품이 기존 정보시스템이나 새롭게 구축하는 정보 시스템과 통합이 불가능하거나 현저한 비용 상승이 초래한 경우
분리발주로 인하여 현저한 비용 상승 초래
정보시스템과 통합 불가능
사업기간내 미완성 나. 현저한 일정지연 : SW제품을 직접 공급하게 되면 해당 사업이 사업 기간 내에 완성될 수 없을 정도로 현저하게 지연될 우려가 있는 경우 다. 현저하게 비효율적 : 분리발주로 인한 행정업무 증가 외에 SW 제품을 직접 구매하여 공급하는 것이 비효율적이라고 판단되는 경우
분리발주 대상 SW 가. 총사업규모가 10억원 이상(VAT포함) 나. 개별 SW가격 5천만원 이상 또는 다량 구매 가격 5천만원 초과 다. GS, 행정업무용, CC, NEP, NET 국가인증 SW 또는 국가정보원 검증/지정 SW ※ 올해 들어 공공기관 발주사업의 상당수가 SW를 분리발주하는 등 SW 분리발주 제도가 어느 정도 정착되고 있으며 하지만 분리발주된 SW 솔루션 비용이 관련 프로젝트가 끝나야 지급되는 점은 개선 ※ 일괄발주와 분리발주 비교

SW산업 선진화 방안의 중장기 전략 분할발주 개요 가. 분할발주의 정의
설계, 개발인력 전문화, 요구사항정의 명확화 등의 목적으로 소프트웨어 개발 단계 별로 나누어 각각 다른 사업자에게 발주
분할발주는 고도의 기술력·창의력을 요구하는 설계와 단순개발 업무가 분리될 수 있도록 프로젝트 발주 자체를 프로세스 별로 나눠서 진행하는 제도
SW사업 분할발주는 건축 분야에서 설계와 시공을 구분해 발주하는 것처럼 SW사업의 분석과 설계, 개발, 구축 등을 단계별로 구분해 발주하는 제도
프로젝트관리조직(PMO)의 감독 아래 요구사업(ISP~설계)과 개발사업으로 분할해 수행하는 발주방식 나. 분할발주의 도입 배경
분석, 설계 역량 및 개발자의 역량 강화
국내 SW 기술수준 향상, 고품질 SW 양산 요구 증대
IT사업 일괄 발주 방식이 시스템통합(SI) 업체 간 과도한 경쟁을 유발
중소기업을 대기업의 하도급 업체로 전락시켜 독자적으로 발전할 수 있는 기회를 가로막음
대형 SI 업체들의 저가 수주 남발과 공공기관의 낮은 이윤율 책정으로 우수 중소 업체가 시장에서 배제되면서 부당 하도급 관행이 없어지지 않음 다. 프레임워크의 필요성

구분 설명 SW사업 관행의 불합리 SW사업관리의 과학적 접근방법인 소프트웨어 공학 기법 적용의 미흡 SW발주 및 관리 지침의 미정착 공공기관 발주관리 및 투명성 확보를 위한 법제도, 표준정착의 한계 추상적인 요구사항 체계화되지 않고 명확, 정량화되지 않은 발주자의 요구사항 증대 SW분리 및 분할발주 이슈 SW대가 지급 문제발생시 책임소재등 불명확한 기준

다. 기존 발주 방식의 문제점 - 요구와 개발이 혼재된 개발문화로 초래된 수∙발주자간 요구사항 갈등 - SW기업의 수익구조 악화 - 과도한 개발자의 업무량과 이에 따른 고급인력의 SW업종 기피 2. 분할발주의 주요특징 및 분리발주와의 비교 가. 분할발주의 주요특징

구분 특징 장점 프로세스 분석, 설계 단계와 개발, 테스트 단계를 분리 공정분리, 품질향상 도입목적 분석, 설계와 같은 고부가가치 업무에 집중 전문개발기술, 전문 테스팅 등 분야별 역량강화 사업이익 실현 전문가 양성 조직구성 분야별 전문가 조직으로 구성운영 개발자는 기술별 조직구성 전문조직의 POOL화 전문 인력 검증 사례 국민은행 등 일부 금융권에서 설계, 개발 이원화 안정적 사업 수행

나. 분리발주와 분할발주의 비교

구분 분리발주 분할발주 개념 HW, SW 및 시스템통합 등을 일괄계약 하지 않고 각각 발주 및 계약 전문 영역인 설계와 단순 개발 업무를 분리하여 발주 목적 하도급제도 개선 SW시장 활성화제고 SW산업구조 선진화 전문적 역량 강화 문제점 통합 및 연계에 대한 책임 모호 설계와 개발 분리 기준 모호 중소 SW기업의 신뢰성 문제 인식 및 제도적 추진 동력 미약 활성화 방안 공공 프로젝트의 엄격한 적용 산학연 연계 통한 인력양성 GS인증, SP 품질인증제도의 확산 ISMP, 신RFP 등 통해 요구 명확화

분할발주 도입을 통한 SW 산업 선진화 방안 가. 공공 프로젝트부터 의무화 실시를 통한 산업구조 혁신 기틀 마련 나. 인력 Pool 제도를 통한 안정적 인력수급체계 구축 다. ISMP를 통한 RFP 명확화로 요구분석 단계의 분할발주 가능 ※ ISMP(Information System Master Plan, 정보시스템 마스터플랜) : 특정 SW개발 사업에 대한 상세분석과 제안요청서(RFP)를 마련하기 위해 비즈니스(업무) 및 정보기술에 대한 현황과 요구사항을 분석하고 기능점수 도출이 가능한 수준까지 기능적･기술적･비기능적 요건을 상세히 기술하며, 구축 전략 및 이행 계획을 수립하는 활동
분할발주의 성공을 위한 고려사항 가. 분할발주에 대한 개념 정립 필요
‘설계와 개발’을 이분화하자는 내용은 명확한 것처럼 보이지만, SW산업에서 설계와 개발을 명확히 구분 어려움 나. ‘SW의 개발∙제조∙생산∙유통 등과 이에 관련된 서비스’는 SW 기업의 업무 영역이고 ‘정보시스템의 구축·운영’은 IT서비스(SI) 기업의 업무 영역(SW산업진흥법 제 2조)
산업 육성을 위한 근거 법이 SW산업을 지나치게 포괄적으로 정의하여, 공공 정보화 사업에서 가장 중요한 정보화전략수립(ISP)∙업무재설계(BPR)∙정보기술아키텍처(ITA)∙IT진단∙IT성과평가∙IT 거버넌스 등 포함되지 않는 허점, ISMP로 보완필요 다. 구체적인 방안을 도출하기 위한 SW사업 선진화포럼 창립 등 주축 확립 필요
분리, 분할발주 적용 시 문제점 및 활성화방안

구분 문제점 활성화 방안 중∙소 SW 구매제도 중∙소기업 우수SW 구매제도의 현실화가 시급함(GS인증 현실화 등) GS인증 SW선구매제도 정착, 법제화 필요 가이드라인 분리발주 가이드라인의 자율성에 따른 실효성에 의문 가이드라인 법률이나 고시 형태로 강화, 강제적용 및 실효성분석 발주제도 관행 덤핑, 가격에 의한 낙찰, 일괄발주 사업범위 모호로 견적이 불가 교육, 홍보 등의 지속적 개선 가격보다 기술 적합성 등에 가점 SW 제값받기 미비 중∙소 업체의 SW대금 지연 선 지급체제의 확립 낮은 가격의 노임 제시 공공의 경우 조달청 선 지급체제 도입, 적용 활성화 분석, 설계 전문가 부족 분할발주 도입으로 인한 영역별 분석, 설계 전문가 필요 분석, 설계 전문교육 체계수립/적용 영역별 Pool제도 도입/활용 개발, 테스팅 전문가 부족 분할발주 도입으로 인한 영역별 개발, 테스팅 SKILL보유자 필요 개발자, 테스트 전문 교육 제도마련 SKILL별 Pool제도 도입/활용

분할발주의 적용형태(예시)

분할발주 적용전 분할발주 적용후

업무 분석/설계자가 분석/설계 후 직접 개발하거나, 개발자에게 작업 요청 (영역별 업무분석, 설계, 개발 진행 형태) 업무 분석/설계전문가 Pool에서 분석, 설계 후 개발Pool로 설계서 인계 작업요청은 업무영역별 개발자에게 직접 요청하는 형태 개발리더(PL)가 SKILL별 인력에게 할당 후 개발 개발 Pool은 Onsite, Offsite, Onsite+Offsite혼합 적용 가능

※ Onsite : 사용자, Offsite : 외주 ※ "분할발주는 품질확보가 핵심 성공요인으로, 공정별 품질보증체계는 기존 모델을 활용할 수 있고, 공정간 품질평가체계는 공정에 따라 모델개발이 필요하다"며 "객관적 품질측정을 위해 정량적 모델개발이 필요하다" 7. 분할발주 성공을 위한 방안

구분 설명 ISMP/ISP 수행 신 RFP 체계에 맟추어 기능 및 비기능 요구사항에 대한 명확화 및 정량화 소프트웨어 분리발주 소프트웨어 분할발주와 함께 분리발주의 병행 수행을 통한 사업관리의 투명성 확보 기술성 평가 ISP 참여업체의 본 사업 참여시 감점제도를 운영하여 본사업과 연계 방지 발주자 부담 최소화 RFP 레파지토리 구성을 통한 Lesson Learned 체계 마련 및 발주자 지원제도 강화 PMO역할 강화 공정별 연계 및 산출물간 통합 테스트 및 연동을 위한 전사적 PMO 역할 강화 SW사업대가 표준화 공정별, 기능별 SW 사업대가의 명확한 기준마련을 통한 체계적 사업 관리

분할발주 주요이슈 및 기대효과 가. 분할발주 주요이슈

구분 설명 불분명한 요구사항 명세화 모듈단위 분리발주에 혼란이 초래되 발주관리가 복잡해지고 시스템 통합 어려움 독립모듈 구분의 어려움 모듈간 구분이 어렵거나 통합기술이 특별히 요구되는 경우 모듈 분할이 어려움 분할발주 책임소재 공정별 연계의 어려움으로 모듈별 통합 및 시험시 불분명한 책임소재 발생 대가지급 기준의 모호성 공정별, 기능별 사업수행에 대한 대가기준의 표준안 미흡으로 인한 이슈 발생

나. 분할발주 기대효과

구분 설명 경쟁촉진 기술력있는 중소기업의 참여기회를 확대하여 가격을 낮추고 시스템 기술 수준 향상을 도모 투명성 향상 프로젝트에 여러 사업자가 참여함으로써 업무 처리나 기술 명세의 리스크가 저하 설계, 개발, 운영 및 유지보수의 투명성이 향상 유연성 향상 시스템 일부에 관계되는 각각의 영향이 전체로 파급되기 어려운 유연한 시스템이 구축 계약의 명확화 불명확한 요구명세로 인하여 잦은 명세 변경이 발생하는 불합리한 계약을 배제 가능 발주자 예산 절감과 품질 향상 사업자 공정한 사업기회와 정당한 대가를 기대

※ 분할발주 프레임워크

가. 공정분할 - 요구사항, 설계, 구현, 시험, 운영 등으로 구분되는 공정분할의 형태로 분할하여 발주하는 방식 나. 기능분할 - 공정에 상관없이 전체 프로젝트를 기능별로 서브시스템으로 분할하는 것 - 각각의 서브시스템은 전체 공정이 다 포함될 수도 있으며, 요구사항, 설계와 같은 공정은 통합하고 구현과 같이 특정 공정에서 서브시스템 별로 분할하여 발주 다. 부품분할 - 각 공정 또는 서브시스템 내의 특정 부품 즉, 패키지 소프트웨어 등을 분리해 내어 발주 ※ 패키지 소프트웨어 기술성 평가기준

구분 평가기준 소프트웨어 기능부문 기능성 사용성 소프트웨어 관리 부문 이식성 유지보수성 소프트웨어 성능부문 효율성 신뢰성 공급업체 지원부문 운용지원 교육훈련 업체신뢰성

※ 분할발주 단계

가. 프로젝트 계획수립 - 전체 프로젝트의 타당성 검토, 범위 및 일정을 수립하고 프로젝트의 비용을 산정 나. 프로젝트 분할전략 - 프로젝트의 분할 방향을 수립 - 공정분할, 기능분할 및 부품분할에 대한 타당성을 검토하고 분할공정에 대한 통합 리스트를 검토하여 분할 전략을 수립하고 분할 공정에 대한 통합계획을 수립 다. 발주 - 각각의 분할공정별로 발주 일정을 수립 - 발주일정은 각각의 분할공정이 완성된 후에 단계적으로 발주하는 것을 원칙 - 발주일정별로 RFP를 작성하여 단계별로 발주 라. 사업관리 - 프로젝트 수행에 대한 실행 및 통제 활동이 이루어지며 품질보증 활동이 수행되고 필요에 따라 내·외부 감리를 수행 마. 인수 및 통합 - 완성된 공정 산출물에 대하여 산출물이 구현된 코드인 경우 인수테스트를 수행하고, 완성된 산출물에 대한 품질평가를 수행하며, 전 공정에 구현된 코드가 있으면 통합 및 통합테스트를 수행 바. 통합 및 종료 - 전 단계에서 인수한 산출물을 통합하여 통합테스트를 수행하고 인수 및 프로젝트를 종료 ※ 분할∙일괄 발주 비교

분할발주 일괄발주 공공기관이 IT 사업 발주 시 하드웨어와 소프트웨어를 포함한 IT 시스템을 구축 단계별, 직무∙기능별로 나눠 발주하는 형태 시스템 통합(SI) 사업자가 사용자에게 최적의 정보시스템을 제공하기 위해 기획∙입안에서 설계와 구축, 운용과 유지보수에 이르기까지 모든 서비스를 일괄적으로 제공하는 발주형태

※ 분할발주시 요구사항 분석을 명확히 하고 재설계 영향도를 최소화하기 위해 내부에 PMO(Project Management Office)를 별도로 구성하거나 별도 발주를 통해 업체를 선정하는 방식을 고려 ※ 업무 및 기능별 분할 발주 방안으로는 정보화 시스템 개발시 업무 및 기능별 단위 시스템으로 분할해 사업자를 선정하는 방안을 추진

오픈소스

GPL, LGPL, BSD, MPL의 정의 가. GPL(GNU General Public License)의 정의 1) GPL을 따르는 소프트웨어 소스코드 일부를 사용해 만든 소프트웨어는 GPL을 따라야 함 2) GPL을 따르는 소프트웨어 소스코드를 개인적으로 사용할 수 없고 반드시 소프트웨어를 개발한 원작자나 공동체에 환원해야 함 나. LGPL(Lesser GPL)의 정의 1) GPL의 1번 조항을 완화한 라이센스 모델 2) LGPL 대상 라이브러리와 링크만 해서 사용한 경우 실행 프로그램에 대한 공개 의무가 없음 다. BSD(Berkeley Software Distribution)의 정의 1) 프로그램의 자유로운 사용, 복제, 배포, 수정을 허용 2) 수정 프로그램에 대한 소스코드 공개를 요구하지 않기 때문에 상용 소프트웨어에 무제한 사용가능 라. MPL(Mozilla Public License)의 정의 1) 모질라(Mozilla)에서 채용한 라이센스 2) MPL하에 배포된 파일 자체를 수정한 경우에만 소스코드 배포 마. 오픈소스 소프트웨어의 개념
SW의 설계도에 해당하는 소스코드를 공개한 상태로 실행 프로그램을 제공하는 SW로, 누구나 자유롭게 소스코드를 사용, 개작, 재배포할 수 있도록 허용
소스코드를 공개해 기술을 공유하도록 하는 것은 누구나 자유롭게 SW의 개발ㆍ개량에 참여하게 하는 것이 우수한 SW를 만드는데 도움이 된다는 생각에 바탕
GPL, LGPL, BSD, MPL 의무사항 가. GPL 의무사항

소스코드 배포시 실행파일 배포시 수정코드 배포시 저작권표시 저작권표시 저작권표시 No Warranty No Warranty No Warranty GPL 배포 GPL 배포 GPL 배포

소스코드 제공 소스코드 제공

수정 사실 및 일자

복제와 유통에는 제약이 없음
사용자가 소스코드를 쉽게 사용할 수 있어야 함
프로그램을 수정할 경우에는 언제, 누구에 의해 수정됐는지를 명시해야 함
GPL SW를 이용해 만든 SW에는 반드시 GPL이 적용돼야 함
GPL라이센스가 적용된 SW를 이용해 개량된 SW를 개발했을 경우 개발한 SW의 소스코드를 공개 나. LGPL 의무사항

소스코드 배포시 실행파일 배포시 수정코드 배포시 저작권표시 저작권표시 저작권표시 No Warranty No Warranty No Warranty LGPL 배포 LGPL 배포 LGPL 배포

소스코드 제공 소스코드 제공

수정 사실 및 일자

다. BSD 의무사항

프로그램 배포시 저작권 표시 No Warranty

라. MPL 의무사항

프로그램 배포시 저작권 표시 No Warranty Exhibit A의 공지사항 표시 Original Code 최초 개발자 Contributors 소스코드 제공 GPL과 BSD의 중간 범위

오픈소스 라이센스 비교

구분 GPL LGPL BSD MPL 코드의 무료이용 ◯ ◯ ◯ ◯ 코드의 자유배포 ◯ ◯ ◯ ◯ 소스코드의 공개 ◯ ◯ ◯ ◯ 소스코드의 수정 ◯ ◯ ◯ ◯ 수정코드의 소스공개 ◯ ◯ X ◯ 상용소프트웨어와의 링크 X ◯ ◯ ◯ 4. GPL 라이센스 Violation(위반)을 예방하기 위한 방안 가. 개발 기획단계 - 오픈소스 SW를 활용할지, 한다면 구체적으로 어떤 프로그램을 사용할지, 또 해당 SW 컴포넌트별로 소스코드 공개가 가능한지 등을 판단 - 사용하는 오픈소스SW의 라이센스 의무사항과 활용하고자 하는 형태에 따라 다양한 경우가 발생하기 때문에 자체적으로 추가 개발한 소스코드 공개를 원하지 않을 때는 상당한 주의가 필요함 - 자체 개발한 소스코드를 공개해도 무방한 경우는 특별히 구현방법에 신경을 쓸 필요가 없지만, 이를 원하지 않을 때는 사용하는 공개SW의 라이센스 의무사항과 활용하고자 하는 형태(커널, 애플리케이션, 디바이스 드라이버 등)에 따라 다양한 경우가 발생하기 때문에 상당한 주의가 요구 나. 개발∙구현(오픈소스 활용) 단계 - 프로젝트 매니저는 개발자가 오픈소스SW를 사용한 경우 해당 라이센스를 삭제하지 않도록 해야 함 - SW 구현 단계 : SW 사용목록을 작성해 제출하게 하는 것이 필요 - 공개SW 라이센스 의무사항 중 저작권 관련문구 유지, 제품명 중복방지, 특허 등은 기획 및 구현단계에서 확인해야 할 사항 다. 개발 완료된 이후 단계 - 개발 계획서에는 라이센스 이슈가 없었다고 해도 개발자가 구현과정에서 오픈소스SW를 라이센스 검증 없이 사용하는 경우가 있을 수 있기 때문에 개발 후에는 소스코드에 대한 실질적인 검증이 필요. 라. 제품화 단계 - 제품화 단계에서는 사용된 오픈소스SW를 라이센스별로 분류하고 각 라이센스에서 준수해야 할 사항이 실제로 제품에 반영될 수 있도록 지속적으로 관리 - 소스코드 공개, 사용여부 명시 등은 제품화 단계에서 확인 5. 오픈소스 소프트웨어(공개 SW)의 도입 배경 - 소스코드가 공개된 공개SW가 개발비용을 줄일 수 있음 - 광범위한 SW개발자(기여자)의 참여로 기술 발전속도가 빠름 6. 오픈소스 소프트웨어(공개 SW)의 도입시 고려사항 - 기업 차원에서 공개SW 정책을 수립 - 정책을 수립할 때는 개별기업이 속한 시장의 상황, 공개SW 발전정도, 개별기업의 기술수준과 비즈니스 모델을 고려 - 공개SW를 활용할 경우 공개SW의 장점(적은 초기 개발비용, 커뮤니티 방식에 따른 빠르고 유연한 개발, SW간에 상호 연동성을 보장하는 오픈포맷과 프로토콜, 강력한 네트워킹 기능 지원)과 단점(애플리케이션의 부족, 빈약하고 체계적이지 못한 문서, 불확실한 개발 로드맵)을 명확히 이해한 가운데 활용여부와 방향을 결정 ※ 삼성전자 : 리눅스의 ‘비지박스’를 사용했지만 소스코드를 공개하지 않아 GPL 라이센스 위반

공개SW 거버넌스 영역

영역 내용 효과 오픈소스SW 영역 공개SW의 3대 요소를 라이센스, 커뮤니티, 방법론으로 정의하고 이해 대한 상세한 정보를 제공 공개SW에 대한 이해 정책 및 가이드 영역 공개SW Governance의 현황을 진단하고, 가이드 기본원칙이 되는 정책을 수립, 사례연구 공개SW를 안전하고 체계적으로 도입 운영 영역 공개SW Governance의 프로세스, 컴플라이언스 팀, 리뷰보드, 공개SW 도입을 위한 전체 프로세스 등을 정립 공개SW Governance를 효과적으로 활용

오픈소스SW 거버넌스 전략 단계 가. 조직의 오픈소스SW 관련 활동 전반을 진단
사용하는 오픈소스SW가 내부용 IT 인프라인지, 고객에게 배포되는 것인지, 오픈소스 프로젝트의 일부인지 또는 다른 제품에 내장된 것인지 등을 조사해 조직 내의 오픈소스SW 활용에 관한 정보를 확인하고 수집
사용하는 오픈소스SW에 통합되거나 함께 배포되는 제3자 제품에서의 오픈소스SW 사용여부를 체크할 필요가 있으며, 그 과정에서 공급사와도 협력하는 것이 중요 나. 기관이나 기업의 오픈소스SW 정책을 구체적으로 결정하게 되는데, 조직의 목표를 명확히 하고, 오픈소스SW 정책을 조직의 목표와 조화
오픈소스SW 정책에서는 오픈소스SW 코드의 사용, 생성, 릴리즈를 위한 공식적인 프로세스를 정의하고, 내ㆍ외부 사용자를 위한 교육 프로그램을 만듦
관련자들이 규정된 절차를 준수하게 하고, 프로세스를 주기적으로 체크해 조정 다. 중요한 정책결정요소의 하나는 어떤 오픈소스SW를 선택하느냐 하는 것이다. 이 경우 일반적인 상용SW처럼 품질이 중요하다. 또 라이센스 조건, 커뮤니티의 크기, 역사, 활동수준 등도 고려 라. 오픈소스SW에 대한 지원도 중요한 일이다. 커뮤니티와의 관계를 유지하면서 직접 지원을 받을 수 있고, 상용기업이나 시스템통합(SI) 기업을 통한 지원을 받을 수도 있다. 마. 오픈소스SW는 관련 커뮤니티를 기반으로 계속 변화하기 때문에 커뮤니티 상황을 지속적으로 추적해야 한다. 취약성이나 치명적인 결함이 드러나지는 않는지, 프로젝트의 건전성과 로드맵은 적절한지, 주요 기여자들이 떠나고 있지 않은지를 파악해야 한다.
공개SW Governance의 목적
공공기관이나 조직에서 정보화 담당자가 오픈소스SW를 도입할 때 오픈소스SW 전반의 이해를 돕고 효율적으로 도입할 수 있도록 표준화된 프로세스와 최적화된 관리방안을 제공하며, 도입, 사용, 유지보수 등에 관한 지침서로서 위험요소를 최소화하는 것을 목적
공개SW Governance의 정의
공개SW를 활용하여 경영가치를 극대화하는 방법과 공개SW의 관리를 통하여 이용의 최적화 및 위험요소 최소화 방안 마련을 위한 공개SW Governance
오픈소스 SW 거버넌스 단계별 활동 및 전략을 위한 단계 가. 단계별 활동

나. 오픈소스 SW 거버넌스 수립을 위한 전략

단계 내용 현황분석 공개SW에 대한 이해를 높이며, 공개SW의 도입실태, 국가정책, 기술 동향 등을 분석 공개SW 거번넌스 프레임워크 수립 IT Governance 프레임워크 Tailoring 통제 등의 관리 기능보다는 지원과 정보제공을 위한 공개SW Governance 프레임워크 구성 구성모델 및 원칙 수립 수립된 공개SW Governance 프레임워크에 따른 정책과 기본 원칙을 정의하며, 도입을 위한 프로세스를 정립 공개SW 거버넌스 고도화 수립된 공개SW Governance의 수요처 확보방안과 수요처 특성에 따른 보급계획을 수립

공개SW 거버넌스의 올바른 방향설정 및 개발을 위해 워킹그룹을 구성하여 지속적인 자문과 검증업무를 수행
오픈SW 가이드라인 지속을 위한 고려사항 가. 향후 자문위원과 실 사용자들의 지속적인 검증을 받아 유기적인 고도화가 필요 나. 안정된 공개SW 사용 환경 조성을 위해 공개SW 라이센스 검증 툴 개발과 지원이 지속 ※ “공개SW는 무엇보다 소스코드에 대한 자유로운 접근이 가능해 최신기술 습득과 SW 기술자립, 개발기간 단축과 비용절감 등 많은 장점이 있다”며 “공개SW의 전략적 활용과 확산을 통해 선진국 기술을 따라잡고 IT와 SW산업을 더욱 고도화할 것 ※ “기업과 정부는 경제 상황이 어려워지면서 각종 IT 투자를 줄였고 이 때문에 전통적인 SW라이센스 대신 공개SW가 주목받기 시작했다”며 “공개SW의 경제성이 입증되기 시작했다” ※ “모바일 애플리케이션 분야에 공개SW는 아직 그 수가 많지 않아 사업으로 성장할 가능성이 크다”며 “개발자 도구나 인프라스트럭처 컴포넌트 등은 포화돼 이 시장은 피해야 한다 우선 기업 현장에서 가장 많은 애로를 겪는 점은 공개SW의 유지보수 계약이다. ※ 공개SW는 기본 프로그램을 무료로 이용할 수 있지만 이를 재가공해 사용하려면 의무적으로 유지보수 계약을 체결해야 한다. 상용SW는 완제품을 공급하고 사후 서비스 개념으로 유지보수를 진행하지만, 이와 달리 공개SW는 라이센스 비용이 없고 유지보수 자체가 비즈니스 모델이 된다는 점에서 상용SW와는 다른 유지보수 개념이 필요하다. ※ `공짜'라는 인식이 강한 탓에 공개SW의 개발 결과물을 활용하는데 따른 저작권 준수도 미흡, 갖가지 소송이 진행되기도 했다. 공개SW가 공개된 소스를 바탕으로 자유롭게 활용할 수 있지만 개발된 SW결과물에 대해서는 개발자가 제시한 라이센스 수준을 지켜야 하는데, 이에 대한 인지가 부족한 것이다. ※ 공개SW 커뮤니티 지원이 부족하고 관련 전문가 육성에 대한 기업의 의지 부족도 문제다. 우리나라 공개SW는 정부 중심의 정책으로 자발적인 커뮤니티 형성이 미흡한 상태인데, 기업들이 공개SW를 활용한 시장형성과 수익창출에 대한 인식마저 부족해 커뮤니티 지원이 열악한 것이다.

오픈소스 소프트웨어의, 시장 모멘텀 형성중 구글의 성공에 힘입어 오픈소스 비즈니스는 스마트폰 및 클라우드 컴퓨팅의 부상으로 본격적인 시장발전 단계로 접어든 것으로 전망됨. 1. 일본의 OSS의 성장 이유 및 시장전망 - 고객의 저비용 지향 트렌드"에 OSS가 최적의 방안 제시 - 가장 많은 수요는 OpenOffice.Org의 오픈오피스 솔루션 - OSS 활용 시장규모는 약 1조 2,000억엔으로 전망 2. OSS의 장점 - 낮은 초기 셋업비용과 소요비용 - 단순한 라이센스 관리 - 신뢰성, 보안, 품질 : 소스코드의 공공적 속성은 신뢰성 높은 수준을 요구 - 저작자의 제품 품질을 공표했다는 확신에 대한 투명성 - 지원 및 책임 : 전매 소프트웨어와 마찬가지로 지원서비스 이용 가능 - 유연성 및 자유 : 벤더에 종속되지 않고 더 많은 관리 권한을 구매자가 가짐 - 공공 협업과 연속성 : OSS 공급업체가 서비스를 중단해도 다른 개발자들에 의한 연속적인 지원 가능 3. OSCON(Open Source Convention) : 주요 IT 벤더들이 참여하여 새로운 사업구상 발표 4. OSS시장이 주류 IT기업들의 지원에 힘입어 시장 모멘텀을 형성하고 있으나 향후 수익모델형성이 OSS비즈니스의 주요 과제로 대두됨 가. 지원서비스를 통한 수익창출 - 오픈소스에서는 누구나 특정프로젝트에 대한 유료 지원 서비스 제공 가능하므로 성공의 관건은 차별화 - 동일한 지원 서비스보다 경쟁 우위 증명 전략 필요 - 표준서비스 수준(SLA)에 의한 협약 이행 능력 향상 나. 상용 엔터프라이즈 버전으로 업그레이드 시 수익창출 - 유료 부가 모듈 모델 - 차별화된 가입형 모델 - 유료 고객에 대한 신속/안정적 서비스 - 유료지원 + 서비스 모델 - 상용패키지 지식 및 교육 모델 ※ 우리나라 공개소프트웨어산업은 정부의 정책적 지원에도 불구하고 여전히 세계에 비해 초기성숙단계에 머무르고 있는 것도 사실이다. 각국의 공개소프트웨어 활동을 지수화한 OSPI(Open Source Software Potential Index)에 따르면 우리나라는 75개 국가 중 산업 활동에서 41위를 차지하는 등 공개소프트웨어 산업 활동과 커뮤니티 활동이 상당히 저조한 것으로 나타났다. 이는 우리 공개소프트웨어 산업이 아직 생산보다는 단순한 활용에 초점이 맞춰져 있기 때문인 것으로 분석된다. ※ 정보통신산업진흥원에서도 공개소프트웨어 커뮤니티를 지원하고, 공개소프트웨어 개발자대회를 개최하며, 개방형 공개소프트웨어 교육센터를 운영하는 등 생산활동의 기반을 마련하기 위한 노력을 강화하고 있다

※ 공개 소프트웨어(SW)에 관한 모든 정보를 한 눈에 찾을 수 있는 한국판 소스포지 ‘공개SW 저장소’가 구축됐다. ※ 지식경제부와 정보통신산업진흥원(NIPA)이 운영하는 공개SW역량프라자는 공개SW에 관한 모든 것을 손쉽게 찾을 수 있는 ‘공개SW 저장소 www.oss.kr’를 구축했다고 밝혔다. ※ 공개SW는 소스코드를 공개해 누구나 제한 없이 코드를 보고 사용할 수 있는 SW로 커뮤니티 활동을 통해 발전되고 배포된다. 하지만, 국내 많은 기업과 개발자들은 유용한 공개SW를 어디서 구해야 하는지 막막한 상황이다. 대부분 공개SW를 해외 사이트에서 찾아야 해 시간과 노력이 많이 소요됐다. 이번에 공개 SW 저장소가 마련돼 국내 공개 SW 적용과 확산이 더욱 빨라질 것으로 기대된다.

※ 오픈소스 SW와 비 오픈소스 SW의 비교

구분 비공개SW 공개SW 공개SW 도입 타당성 성능 규모가 큰 환경에서 비교적 높은 성능 다양한 환경에 최적화된 성능 HW의 기술발전으로 비공개SW와 비슷하거나 우수한 성능 제공 비용 SW구입 라이센스 비용 지불 비용이 적거나 없음 다수의 업체로부터 공급이 가능하며, 총소유비용(TCO) 절감측면에서 높은 경쟁력 유지보수 독과점에 의한 가격 결정 서비스 수준에 따른 가격결정 보안 폐쇄적 운영으로 공개되지 않은 취약점 존재 소스공개에 따른 취약점 분석 용이 취약점은 존재하나 허점 발견 및 대응속도가 높음

※ 오픈소스SW는 라이센스 비용이 무료이고, 소스코드가 공개돼 누구나 쉽게 쓸 수 있고, 복제ㆍ사용ㆍ개작 및 배포가 자유로워 전 세계적으로 널리 확산되고 있다. ※ 전문가들은 오픈소스SW 확산 저해요인이 오픈소스SW에 대한 특성, 비오픈소스SW와의 차이점에 대한 이해 부족 등이라고 보고 있다. ※ 정보통신산업진흥원(원장 정경원)이 최근 발표한 `오픈소스SW 거버넌스 2.0'은 이해관계자에게 오픈소스SW에 대한 계획수립 및 조직화, 획득 및 구현, 유지보수 서비스, 성과평가 등 라이프사이클 전반에 대한 지침을 제공한다. 특히 오픈소스SW의 효율적이고 효과적인 도입을 위한 프로세스에 대해 기획자, 개발자, 운영자 관점에서 수행해야 할 책임과 역할을 정의했다. ※ 오픈소스SW 거버넌스 2.0에 따르면, 오픈소스SW를 도입, 적용하기 위해서는 목표하는 비즈니스 전략을 효과적으로 수행할 수 있는 미래지향적이고 일관성 있는 지원틀을 수립해야 한다. 또 오픈소스SW 라이센스 조건, 커뮤니티의 크기ㆍ역사ㆍ활동수준, 소송가능성을 포함한 법적상황도 고려하고 어떤 경로를 통해 필요한 SW를 획득할지를 정해야 한다. ※ 또 오픈소스SW는 조직 내의 개발자나 운영자 역량에 따라 패치, 업그레이드 등의 유지보수 활동을 수행할 수 있지만, 최적의 상태로 운영ㆍ유지하기 위해서는 전문 기술지원업체와 계약해 기술지원을 받는 것이 유리하다. ※ 오픈소스 도입효과

분야 내용 경제적 효율성 도입 및 유지보수 비용 절감 시간 및 인력 등의 개발 투입 비용 절감 신규사업 원가 경쟁력 향상 시장경쟁 촉진 상용 소프트웨어 업체와 시장경쟁 촉진 가격 경쟁력 확보로 소비자에게 다양한 대안 제시 종속성 극복 운영체제 및 DBMS 등의 글로벌 상용 소프트웨어 제품의 종속 문제 해결 기술혁신 개발, 공개, 지속적 보완 과정을 통해 성숙한 소프트웨어 개발 환경 조성 수정 및 재배포 가능한 라이센스로 뛰어난 소프트웨어 출시

SW(소프트웨어) 라이센스(License)
저작권자로부터 일정한 범위와 조건 안에서 SW를 사용할 수 있도록 허락 받는것
SW 라이센스의 유형은 사용기간, 사용기준, 공급형태 등을 기준으로 나눔
사용기간
사용기간을 기준으로 영구, 기간, 임시 라이센스로 나눌 수 있음

구분 설명 영구 라이센스 한번 구매하면 계속 사용할 수 있는 라이센스로, 대부분의 패키지 SW 기간 라이센스 저작권사가 정해놓은 일정기간 동안만 사용할 수 있는 라이센스 임시 라이센스 계약 후 비용납부가 될 때까지 임시로 발급되거나 전시, 컨벤션, 국제회의 등의 행사를 위해 임시로 발급되는 라이센스

사용기준
사용자 수를 어떤 기준으로 정할 것인가에 따른 분류로, 기업 내부 환경에 따라 적당한 라이센스를 선택하면 상당한 비용절감 효과를 볼 수 있음

구분 설명 1인1PC 라이센스 PC 1대에 1개의 SW를 설치해야 하는 가장 일반적인 라이센스 동시사용자 라이센스 동시에 사용하는 사람을 몇 명까지 허용할 것인가를 정하는 라이센스 사이트 라이센스 PC수나 사용자수를 특정하지 않고 해당 회사나 특정 장소 내에서는 무제한으로 사용할 수 있도록 허락하는 라이센스 프로세서 라이센스 사용자 수와 관계없이 서버의 CPU 개수에 따라 정해지는 라이센스 서버접속 라이센스 서버에 접속할 수 있는 권리로, CAL(Client Access License)

공급형태
공급형태를 기준으로 하면 패키지 라이센스, 볼룸 라이센스, SaaS(서비스로서의 SW), 번들 SW로 나눌 수 있음

구분 설명 패키지 라이센스 박스 포장된 형태로 판매되는 SW 볼룸 라이센스 일반적으로 라이센스 계약이라고 통칭하는 형태로, 계약서에 사용자 수와 회사명을 명시해 서로 서명을 한 후 라이센스 증서를 받게 됨 SaaS 라이센스 SW를 웹 등을 통해 제공받는 서비스 형태 번들SW 라이센스 HW(하드웨어)와 함께 제공되는 SW로, PC나 노트북 구입 시 이미 설치돼 있는 SW 등이 이에 해당

< 공개SW 유지관리 서비스 시점 >

구 분 시스템 구축 단계 또는 도입단계 1차년도 2차년도 상용SW 사용권(라이센스) 계약 무상 (사용권 도입가에 포함됨) 유지관리 요율 적용 (사용권 도입가*요율) 공개SW 사용권 무상 컨설팅 비용 + 1차년도 유지관리 서비스 계약 - 유지관리 서비스 계약

<공개SW 유지관리 서비스 항목>

구분 유지관리 서비스 항목 유지관리 서비스 내용 제품지원 설치 및 기능향상 설치지원 초기 설치 및 환경설정 메이저 기능향상 메이저 업그레이드 제품 제공 및 설치지원(예, Ver 1.0 → Ver 2.0) 마이너 기능향상 마이너 업그레이드 제품 제공 및 설치지원(예, Ver 1.0 → Ver 1.1) 제품 수정 및 업데이트 패치 /Hotfix 보안 패치와 SW 제품의 버그 등 오류를 수정하는 업데이트 제공 및 설치 지원 공개SW 라이선스 보증 공급한 공개SW 제품의 라이선스 사용에 대한 법적 문제가 없다는 것을 보증 유지관리 기본유지관리 고객지원 사이트 접속, 전화/이메일 등 원격 일상지원 긴급 장애지원 사용자가 긴급한 문제를 해결하기 위해 장애처리 및 정비 서비스를 요청한 경우 고객을 지원 예방지원 시스템 장애를 사전예방하기 위해 정기적으로 지원하는 정기 점검 서비스 교육 제품 운영 및 사용을 위한 운영자/사용자 교육 성능 개선/튜닝 운영시스템의 성능 개선과 튜닝을 위한 전문 서비스 컨설팅 서비스 아키텍처 재설계 운영시스템의 아키텍처 재설계를 위한 전문 서비스 기타 전문 서비스 기타 운영시스템 환경 고도화를 위한 전문 서비스

<공개SW 유지관리 서비스 수준> (O : 온라인, ◎ : 온라인/온사이트)

구분 유지관리 서비스 항목 유지관리 서비스 수준* 기본 표준 고급 제품지원 기능향상 메이저 O O ◎ 마이너 O O ◎ 제품 수정 및 업데이트 패치/Hotfix O O ◎ 공개SW 라이선스 보증 O O O 유지관리 기본 유지관리 O O O 긴급 장애지원 O ◎ ◎ 예방 지원 - O ◎ 교 육 - ◎ ◎ 성능 개선/튜닝 - - ◎ 컨설팅 서비스 아키텍처 재설계 개별 협의 기타 전문 서비스 개별 협의

기본서비스 (정의) 공개소프트웨어 제품을 도입해서 운영하기 위한 가장 기본적 서비스 수준 (예시) 웹서버, 파일서버, 백업서버 등 시스템 중요도가 낮은 단일 서비스형 시스템을 운영하기 위한 유지관리 서비스 표준서비스 (정의) 상시적 운영 이외 예방항목을 추가하여 보다 안정적인 서비스를 수행하기 위한 서비스 수준 (예시) 중소규모의 대내외 서비스형 업무 시스템에 적용 가능한 유지관리 서비스 고급서비스 (정의) 온 사이트를 통한 보다 질 높은 서비스 수준 (예시) 시스템 중요도가 높고 이중화가 필요한 핵심업무 시스템에 적용 가능한 유지관리 서비스

< 긴급장애, 예방지원의 세부 서비스 수준 >

유지관리 서비스 항목 유지관리 서비스 수준* 지원시간 응답시간 (업무시간 기준) 지원횟수 기본 표준 고급 긴급 장애지원 O

8h*5/주 8시간 이내 무제한

◎

24h*5/주 8시간 이내 온라인-무제한 온사이트-개별협의

◎ 24h*7/주 4시간 이내

기본 표준 고급 지원시간 응답시간 지원횟수 예방 지원

협 의

연 2회

◎ 협 의 - 연 4회

긴급 장애지원의 응답시간은 업무시간을 기준으로 하며, 이외 시간은 별도 협의 <계약 단계별 검토사항>

단계 검토 사항 (1) 예산 확보단계 공개SW는 운영비용 관점에서 정액제로 예산을 편성 [산출 방식] (통합발주 시) = (상용SW도입가*요율)+공개SW유지관리 비용 (공개SW 단독발주 시) = 공개SW유지관리 비용 (2) 발주 단계 상용SW 유지관리 및 공개SW유지관리서비스 발주를 구분하여 명기 (3) 유지관리 계약 단계 1차년도 이후 연간(or 다년) 단위로 정액 계약 체결 (4) 사업관리 단계 발주기관은 원/하도급자 간 공개SW 유지관리서비스 계약 체결 및 지급여부 확인

공개SW 프로세스 ▣ 공개SW 프로젝트 생명주기 공개SW 프로젝트는 SW 개발이라는 관점에서는 기존의 많은 상용 SW와 유사한 생명주기를 갖게 된다. 하지만 공개SW 프로젝트에서는 ‘공개’라는 단어가 함축하듯이 여러 명의 개발자가 참여하는 분산 개발, 기존에 공개되어 있는 많은 SW 자원의 이용, 다양한 부류의 자원자들에 의한 SW 리뷰 및 시험 과정, 기술 지원 방법, 기능의 확장, 새로운 프로젝트로의 가지치기(Branching) 과정 등이 비공개 SW와 달리 매우 중요한 의미를 가지게 된다.다음의 그림은 공개SW 프로젝트의 생명주기를 포괄하고 있다. 【그림 II-17. 구문 테스팅 예제】

▣ 공개SW 프로세스 공개SW기반 개발에 있어서 일반적으로 적용되는 프로세스는 다음과 같다. 【그림 III-4. 일반적인 공개SW기반 방법론기】

공개SW 프로세스는 SW공학 관점에서 비슷한 절차에 따라 수행되고 있으나, 공개SW에 많은 영향을 주고 있는 분산 네트워크에서 다양한 동기를 가진 자발적 참여자들의 복잡한 상호작용을 통해 이루어지는 커뮤니티의 특성에 따른 방법론을 적용하는 것을 고려하여야 한다. ● 공개SW 테스트 활동 공개SW 프로세스에서 수행할 수 있는 테스트 활동은 표준화 테스트, 소스 리뷰, 기능/비기능 테스트, 라이선스 검증으로 분류할 수 있으며 상세 내용은 다음과 같다. 【표 III-1. 공개SW 테스트 활동 상세 내용】

분류 테스트 종류 내용 표준화 테스트 LSB (Linux Standard Base) LSB 인증 서비스를 받고자 하는 기관/기업에게 LSB 인증 프로세스 정의 및 수행방안 제시, 도구 및 활용정보 제공 LTP (Linux Test Project) 리눅스 운영체제에 대해 Tool을 활용한 리눅스의 신뢰성, 호환성, 안정성 테스트 수행 소스리뷰 피어리뷰 같은 분야의 전문가들이 저자의 결과물을 심사하는 과정 소스 인스펙션 완성된 코드에 대한 검토를 통해서 코드 상에 존재하고 있는 잠재적인 문제를 발견하는 과정 기능/비기능 테스트 자동화 도구 테스트 도구를 활용한 기능/비기능 테스트 수행- 기능 테스트(기능별 정확성 시험, 다양한 조합의 테스트 등)- 비기능 테스트(Stress Test/Endurance Test/Usability Test 등) 시나리오 기반 테스트 시나리오 기법을 적용한 테스트 케이스를 이용하여 기능/비기능 테스트 수행 라이선스 검증 Code Eye 한국저작권 위원회에서 개발하고 서비스하는 공개SW 라이선스 검증 도구 Protex IP 블랙덕 SW에서 개발한 오픈소스저작권관리 SW FOSSology 공개SW 라이선스 관련 문자열을 검색하기 위한 공개SW

공개SW 테스트 도구 소프트웨어 테스트 자동화를 위한 공개SW 테스트 도구들이 많이 소개되어 있으며, 이러한 도구들은 쉽고 효율적인 소프트웨어 테스트 수행을 지원한다. 하지만 테스트 도구를 사용하는 것은 장점뿐 아니라 단점 역시 포함하고 있으므로 테스트 도구에 대한 이해를 통한 적절한 도구를 선택하는 것이 필요하다. ▣ 테스트 도구의 장점 ● 테스트 데이터의 재입력 같은 반복 작업의 자동화 ● 요구사항의 일관성과 반복의 가능성 ● 정적인 측정값 등 객관적인 평가 기준 제공 ● 성능에 대한 통계와 그래프 등 테스트 정보에 대한 쉬운 접근 ▣ 테스트 도구의 단점 ● 도입 후 프로세스 적용에 대한 시간, 비용, 노력에 대한 추가 투자 ● 도구의 사용에 필요한 노력과 시간에 대한 추가 투자 ● 비공개 상용SW의 경우 고가이며, 유지 관리 비용이 높음 ▣ 테스트 활동에 따른 도구 분류

테스트 활동 테스트 도구 내용 테스트 계획 요구사항 관리 고객 요구사항 정의 및 변경사항 관리 테스트 분석/설계 테스트 케이스 생성 테스트 기법에 따른 테스트 데이터 및 케이스 작성 커버리지 분석 대상시스템에 대한 테스트 완료 범위 척도 테스트 수행 테스트 자동화 기능 테스트 등 테스트 도구를 활용하여 자동화를 통한 테스트의 효율성을 높일 수 있음 정적분석 코딩표준, 런타임 오류 등을 검증 동적분석 대상시스템 시뮬레이션을 통한 오류 검출 성능 테스트 가상사용자를 인위적으로 생성하여 시스템 처리능력 측정 모니터링 시스템 자원(CPU, Memory 등) 상태 확인 및 분석 지원 도구 테스트 통제 형상관리 테스트 수행에 필요한 다양한 도구 및 데이터 관리 테스트 관리 전반적인 테스트 계획 및 활동에 대한 관리 결함 추적/관리 테스트에서 발생한 결함 관리 및 협업 지원

SW관리 라이프 사이클 개념도

구분 설명 기반구축 SW 관리를 위한 기반을 구축하는 단계 SW 관리의 중요성을 직원들에게 인지시키고 SW 관리의 기본적인 체계를 마련하는 등의 일을 하게됨 정책과 절차수립 SW 관리를 위한 정책과 절차를 수립하는 단계 전체 SW 관리 라이프사이클을 수립하고 셰어웨어 SW 등의 사용정책, 포상과 징계절차, 지속적인 유지를 위한 정책 보급과 재평가하는 단계 정책과 절차를 준수하려는 경영진의 강력한 의지표명이 중요 조사, 분석 SW 사용 실태 조사와 현황 분석 단계 설치돼 있는 SW를 조사하기 위해 점검용 SW를 설치하고 SW 관리상태, 문제점 등을 파악 보완, 정비 분석된 결과를 토대로 보완조치를 취하고 관리체계를 정비하는 단계 파악된 불법 SW에 대해 조치를 취하고 SW 관리대장 등을 작성해 정기적인 SW 관리 기반을 만듬 교육 및 지속적 유지 내부규정 등을 정비하고 SW 수요조사 및 구매, 점검, 교육 등을 주기적으로 반복함으로써 SW 관리체계를 유지해 나감

ISO

소프트웨어 품질보증의 제품평가 분야의 국제표준 ISO 9126의 개요 가. ISO 9126의 정의
제품평가 분야에 대한 표준으로 소프트웨어 제품에 요구되는 품질을 정량적으로 기술하거나 소프트웨어 품질을 측정하는 척도
소프트웨어 품질의 특성을 정의하고 품질 평가의 Metrics를 정의한 국제표준으로 사용자 관점에서 본 소프트웨어의 품질 특성에 대한 표준
소프트웨어 품질의 특성을 정의하고 품질 평가의 Metrics를 정의한 국제표준 나. ISO 9126의 구성

구분 분류 내용 ISO 9126-1 주특성과 부특성 소프트웨어 품질 주특성/부특성과 매트릭 소프트웨어 품질 특성과 Metrics ISO 9126-2 외부매트릭 (External Metrics) 소프트웨어가 사용될 때의 외부적 성질 표현 실행가능 소프트웨어 시험/운영으로 측정 소프웨어의 사용자/관리자 관점 ISO 9126-3 내부매트릭 (Internal Metrics) 설계/코드와 관련된 소프트웨어의 내부 속성을 측정 설계/코딩 중인 소프트웨어 제품에 적용 SW 설계/코드와 관련된 개발자관점 ISO 9126-4 사용매트릭 (Use Metrics) SW 특정 관점들을 중점으로 품질 평가

다. ISO 9126의 필요성 - 사용자, 평가자, 시험관, 개발자 모두에게 소프트웨어 제품의 품질을 평가하기 위한 지침 필요 - 평가대상 소프트웨어의 품질을 직접 측정하기 위해 필요한 평가 Metrics의 준비 - 소프트웨어의 품질을 객관적이고 계량적으로 평가할 수 있는 기본적 틀 필요 2. ISO 9126의 소프트웨어 제품의 품질특성 및 품질평가 절차 가. ISO9126 소프트웨어 제품의 품질특성

주특성 설명 기능성 (Functionality) 사용자 요구사항 충족도 명시적 또는 묵시적 필요를 만족하는 기능이 S/W에 존재하는지 판단 신뢰성 (Reliability) 명시된 기간/조건, 품질유지 능력 성능수준을 유지하는 능력 사용성 쉬운 이해, 사용 편리한 능력 사용의 편리성 및 사용자 호감도 효율성 (Efficiency) 투입자원대비 자원소요정도 소프트웨어 성능과 사용된 자원의 양사이의 관계 유지보수성 (Maintainability) 요구사항/환경변화 적용성 소프트웨어 수정에 필요한 능력 이식성 (Portability) 타 SW/시스템 이전 용이성 소프트웨어가 다른 환경으로 이전될 수 있는 능력

주특성 부특성 기능성(Functionality) 적절성, 정확성, 보안성, 상호호환성, 유연성 신뢰성(Reliability) 성숙성, 오류허용성, 회복성 사용성 이해성, 운용성, 습득성 효율성(Efficiency) 시간효율성, 자원효율성 유지보수성(Maintainability) 시험성(testability), 안정성(stability), 분석성(analyzability), 변경용이 이식성(Portability) 적응성, 일치성, 이식작업성, 치환성

※ 성숙성(Maturity) : ISO 9126-2 External metrics에 포함되어 있는 MTBF(Mean Time Between Failure)측정

소프트웨어 품질 특성의 모든요소들을 동시에 만족할 수 없으므로 Trade-off 유지 나. ISO9126에 따른 측정결과와 판정등급 예시
ISO9126의 측정된 결과에 따라 판정등급이 만족(구매)와 불만족(구매거부)로 구분

다. 품질평가 절차

구분 설명 명세서 요구사항 정의 대상 소프트웨어 품질요구 정의 평가의 목적 설정, 제품 유형 식별, 품질측정을 위한 모델 등을 정의 품질 요구 명세서 기준정의 매트릭 선정, 등급 기준 정의, 평가기준 정의 평가를 위한 측정요소와 측정세부 체크리스트 선택, 측정결과 판정등급 및 판정기준을 설정 등급 기준 명세서 등급부여 매트릭, 기준별 측정, 등급부여 평가시나리오를 포함하는 평가계획을 작성하며, 평가에 사용할 테스트 케이스를 설계 등급 적용 명세서 평가 등급별 평가기준 적용, 수용/거절 평가 설계에 제시된 특성과 기준을 토대로 측정 요소별로 측정하고, 측정 결과값을 판정하여 제시된 기준과 비교 평가 평가결과/인증서

라. 평가결과 및 결과의 바람직한 특성 - 반복성(Repeatability) : 어떤 하나의 제품에 대해 동일 평가자가 동일한 사양(동일한 제품, 동일한 평가명세 및 기준, 동일한 측정 데이터 등)에 따라 평가했을 때 동일한 것으로 간주할 수 있는 결과가 도출 - 재생산성(Reproducibility) : 어떤 하나의 제품에 대해 다른 평가자가 동일한 제품, 동일한 평가명세 및 기준에 의해 다른 데이터로 측정했을 때 동일하다고 여겨질 수 있는 결과가 발생 - 공평성(Impartiality) : 평가가 특정결과에 편향되지 않음. 즉, 목적의식을 갖고 평가결과를 임의로 유도해서는 안됨. - 객관성(Objectivity) : 평가결과가 평가자의 감정이나 사견에 의해 영향을 받지 않아야 함 마. ISO9126의 평가에 의한 품질결과 판정 - 결과 판정은 소프트웨어 평가 절차의 마지막 단계로, 일련의 판정된 등급들을 요약하며, 대상 소프트웨어가 품질요구사항을 충족하는 가를 판정 - 요약된 품질 측정 결과를 시간과 비용 등 품질 이외의 측면과 견주어 요구 충족 수준을 가늠해 볼 수 있음 - 측정된 결과, 비교 자료 및 관리기준을 토대로 의사결정을 하는 관리층(또는 경영층)이 결정을 내려야 함 - 내려진 결정에 의해 제품의 구매(인수) 또는 거부 의사와 배포에 관한 의사결정을 완료 3. ISO9126 기반의 기능성 측정방안 가. 기능성의 적합성(업무형태) 측정 - 제품설명서와 사용자문서에 업무에 이용하는 서식작성에 관한 기능 정보를 제공하고 있고, 제품설명서와 사용자문서에 기술되어있는 서식작성기능이 제대로 구현되어 있는지를 평가

나. 기능성의 적합성(업무절차) 측정 - 프로그램이 업무를 수행하는 절차에 따라 원하는 기능을 수행할 수 있는지 평가

다. 기능성의 정확성 측정 - 구매하고자 하는 제품이 구매자의 요구하는 기능을 갖추고 있는지 여부와 요구하는 수준에 부합하는지 여부를 평가하고, 제품설명서에 제시하는 기능이 정확하게 구현되고 있는지도 평가함

공공사업에서의 ISO9126 기반의 기능성 측정사례 가. 품질평가표

나. 품질평가내역

범례) 요구사항 추적율 A : 현재 개발단계 산출물의 요구기능 수 B : 이전단계의 산출물이 없으나 현재 단계에서 존재하는 기능수 C : 이전단계의 산출물이 있던 기능이 현재 단계에서 존재하지 않는 기능수 표준 준수율 A : 산출물의 총 항목 수 B : 산출물 작성 표준 및 지침에 위반되는 내용을 포함하는 항목 수 5. ISO 9126의 현황 가. 품질 모델평가 중심의 ISO 9126, 평가절차 및 방법 중심의 ISO 14598을 통합한 SQuaRE(Software product Quality Requirements and Evaluation, ISO25000)로 표준화 나. 국내 환경에 부합되는 평가 모델 및 법적 보호 차원의 GS인증(ISO9126+14598) 제정

※ 소프트웨어 제품에 요구되는 품질을 정량적으로 측정하는 표준은 ISO/IEC 9126, ISO/IEC 14598, ISO/IEC 12119가 존재한다 ※ ISO/IEC 14598은 소프트웨어 제품의 품질을 측정하거나 평가 하는데 필요한 방법과 절차를 정의하고 평가 명세서 작성, 평가계획수립, 평가수행 및 결과도출 등의 단계를 제시하고 평가 명세서작성 시에 ISO/IEC 9126에 따른 내부 및 외부 매트릭스 활용이 가능하다 ※ ISO 14598 : 소프트웨어 제품을 객관적이고 공정하게 평가하기 위한 방법 및 절차를 규정 ※ ISO 12119 : ISO 9126의 품질 모델을 기반으로 하여 소프트웨어 제품품질 요구사항 및 테스팅 절차를 규정 ※ SQuaRE(Software Quality Requirement and Evaluation : ISO 25000)은 ISO/IEC 9126과 ISO 14598을 보강, 통합하는 새로운 소프트웨어 평가 모델이다. [SQuaRE 4+1 구조] 1) 품질모델(25010 Quality Model Division) 2) 품질 매트릭스(25020 Quality Metrics Division) 3) 품질 요구사항(25030 Quality Requirement Division) 4) 품질평가(25040 Quality Evaluation Division) 5) +(Plus) 전체를 반영하는 부분(25000 Quality Management Division)

I. 소프트웨어 제품 평가 프로세스, ISO 14598의 개요 가. ISO 14598의 정의 - 개발 중이거나 완성된 제품을 객관적이며 공정하게 평가하기 위한 방법, 절차 - 소프트웨어 제품평가에 대한 국제적인 표준으로 ISO 9126의 사용을 위한 절차와 기본 상황 및 소프트웨어 평가 프로세스에 대한 표준 규정한 국제 표준 - 소프트웨어 제품 평가에 대한 표준으로 품질 평가 절차를 “평가 요구사항 설정”, “평가명세”, “평가설계”, “평가수행” 등 4 단계로 구분 - SW 개발 과정 또는 개발된 제품 형태의 SW 품질을 객관적으로 측정하고 평가하는 과정으로 SW 제품 평가에 대한 국제 표준 - S/W 제품 평가에 대한 국제적 표준으로 ISO9126의 사용을 위한 절차와 기본 상황 및 S/W 평가 프로세스에 대한 표준을 규정 한 표준 나. 도입배경

구분 내용 신뢰성 확보 소프트웨어 제품에 대한 기술력 공인 동기부여 소프트웨어 개발에 대한 품질 향상 동기부여 제품선택 기준 소프트웨어 품질이 제품선택의 기준으로 대두됨

다. ISO 14598의 특징

특징 내용 반복성 (Repeatability) 어떤 하나의 제품에 대해 동일 평가자가 동일한 사양(동일한 제품, 동일한 평가명세 및 기준, 동일한 측정 데이터 등)에 따라 평가했을 때 동일한 것으로 간주할 수 있는 결과가 도출되어야 함 재생산성 (Reproducibility) 어떤 하나의 제품에 대해 다른 평가자가 동일한 제품, 동일한 평가명세 및 기준에 의해 다른 데이터로 측정했을 때 동일하다고 여겨질 수 있는 결과가 발생하여야 함 공평성 (Impartiality) 평가가 특정결과에 편향되지 않음. 즉, 목적의식을 갖고 평가결과를 임의로 유도하여서는 안됨. 객관성 (Objectivity) - 평가결과가 평가자의 가정이나 사견에 의해 영향을 받지 않아야 함 - ISO 9126시리즈에 규정한 표준 준수

ISO 9126 시리즈에 규정한 표준 준수
품질평가의 측정기술, 측정결과의 해석 방법 등은 규정하고 있지 않음 II. 제품평가 국제 표준 관계도
ISO/IEC 14298은 SW품질 평가와 패키지SW 요구사항 시험 표준 III. ISO 14598과 품질특징(ISO 9126)과의 관계 및ISO 14598 구성 가. ISO 9126과 14598의 관계

-14598-1에서는 ISO 14598 평가 항목과 ISO 9126 평가 항목을 포괄함

14598-6/14598-3 그룹핑 : 개발자
14598-2/14598-4 그룹핑 : 획득자
14598-6 : 9126의 외부 매트릭스와 내부 매트릭스가 Input 나. ISO 14598의 구성

구성 내용 비고 ISO 14598-1 - General Overview - 14598 시리즈 전체와 ISO9126 품질 모델과 관계 설명

ISO 14598-2 - Planning & Management - 제품 품질 측정 계획의 준비와 구현뿐만 아니라 제품 평가 기능의 관리를 위한 전체적인 계획 수립 제품 평가에 대한 계획 및 관리 ISO 14598-3 - 개발자를 위한 프로세스 제공 제품의 품질 예측, 품질지표 ISO 14598-4 - 구매자를 위한 프로세스 제공 제품선정, 인수 지표 ISO 14598-5 - 평가자를 위한 프로세스 제공 독자적 평가 수행 ISO 14598-6 - 평가 모듈 및 문서화 평가 모듈, 문서화 지침

IV. ISO 14598의 구성에 대한 상세설명 가. ISO 14598-1 - General Overview - 14598 Series 전체와 ISO 9126 품질 모델과 관계 설명 나. ISO 14598-2 - Planning and Management - 소프트웨어 제품 평가를 위한 지원 기능의 역할에 대한 권고 및 지침 - 평가 관리 개념(지원 기능의 역할) : 표준설정, 데이터 수집 및 분석, 도구 개발, 평가 기술 확보 및 이전 - 소프트웨어 평가지원 요구사항· 평가 계획 수립의 주요사항 · 조직적인 차원에서 평가 기술 관리 · 프로젝트 관리를 위한 지원개요 다. ISO 14598-3 - Process for Developers - 소프트웨어 개발단계에서 개발자가 준수해야 할 내용에 대한 표준 - 조직 및 프로젝트 요구사항· 평가요구사항의 도출 및 타당성 분석 · 평가내용의 명세화 · External 및 Internal Quality 요구사항(Attributes, Target Values 정의) · 평가 계획 설계(Internal 및External Evaluation) · 평가 수행(중간단계 제품 및 최종 제품) 및 평가 결과 도출 라. ISO 14598-4 - Process for Acquirers(획득자 프로세스) - Off-the-Shelf 소프트웨어 및 기존 소프트웨어 수정에 관하여 구매자가 준수해야 할 내용에 대한 표준(ISO 12207의 구매절차와 연계하여 수행) - Off-the-Shelf 소프트웨어 구매 시 평가 · 시스템, 소프트웨어 평가 요구사항 도출 · 평가내용의 명세화 · 매트릭스 및 평가방법 선택 · 평가 계획 설계 · 평가 수행 및 결과 분석 · 결과 도출 - 기존 소프트웨어 수정의 경우 평가 · 평가 요구사항 도출 · 평가내용의 명세화 · 평가 계획 설계 · 평가 수행 개요 마. ISO 14598-5 - Process for Evaluators(평가자 프로세스)

평가절차 내용 평가요구사항 설정 - 평가의 목표를 기술 - 제품에 대한 품질 요구사항 기술 평가명세 - 소프트웨어 제품과 구성요소에 대해 수행될 모든 분석과 측정을 정의 - 평가 요구사항에 기반을 둠 - 신청자가 제공한 제품설명서에 기반을 둠 평가설계 - 평가명세에 따라 수행하기 위한 절차를 기술 - 평가명세에 기반을 두고 평가계획을 생성 - 평가자가 제안하는 평가방법과 평가될 소프트웨어제품의 구성요소를 고려 평가수행 - 평가계획에 따라 평가 수행 - 평가자가 수행한 활동이 기록되며 얻어진 결과가 평가 기록의 초안에 정리 - 평가 기록에는 평가 요구사항, 평가 명세, 측정과 분석 결과, 평가를 반복하거나 재현하기 위해 필요한 정보, 평가계획, 평가자가 수행하는 활동을 기록 평가결론 - 평가보고서 검토 - 평가데이터 처분에 대한 검토

바. ISO 14598-6 - Documentation of evaluation modules(평가모듈) - 매트릭스의 문서를 위한 표준 필요(평가모듈) - 14598-3,4,5의 평가기술, 매트릭스 선정 등에 활용 - EM은 14598-2에 따라 Library 형태로 관리

구분 항목 내용 EM0 개요 서론 및 소개 모듈목적, 개념, 배경설명 EM1 범위 품질특성, 평가수준, 적용기술, 적용범위 적용대상, 품질특성, 부 특성, 적용기술 및 적용범위 등을 기술 EM2 참조규격 관련규격 평가모듈과 관련된 기술 EM3 용어 및 정의 용어정의 평가모듈에 사용된 용어 정의 EM4 입력요소와 매트릭스 입력요소 정의, 데이터요소, 매트릭스 정의 평가에 이용되는 입력요소의 구분, 입력 값의 상세 설명, 매트릭스 계산식 EM5 결과 해석 결과판정, 결과보고서 판정 가능한 값으로 변환, 평가결과 보고서 EMA 적용절차 소요자원, 평가지침 소프트웨어, 하드웨어, 도구, 기술 및 지식 등 시료선정, 결과 계산 등 최종 기록 사항

V. ISO 14598의 도입효과 및 향후 전망 가. ISO 14598의 도입효과

구분 도입효과 개발자 측면 - 객관성을 가진 소프트웨어 품질에 대한 지표의 사용 또는 활용 - 품질 높은 소프트웨어를 제품으로 개발하기 위한 자발적 참여 소비자 측면 - 객관적 품질 지표에 의해 평가된 제품의 정보를 용이하게 획득 - 필요한 요구사항에 대한 기준으로 적용하여 제품을 선정하거나 구매에 관한 의사결정을 용이하게 정보 제공 유통체계 - 구매자와 소비자 간의 의사소통을 위한 도구로 활용 - 시장에서 품질 높은 제품을 요구하기 때문에 진입장벽을 수립

나. 향후 전망 - 소프트웨어 제품을 도입하는 시점에 선택하는 방법으로 제품평가의 중요성은 심화됨 - 시장 내 가장 활성화가 예상되는 컴포넌트 소프트웨어의 품질평가를 위한 체계 구축이 필요 - 국내 표준을 위한 기관간 영역 조정과 협력을 위한 체제 구축 - 소프트웨어 품질보증 기술력 강화와 표준 개발노력을 확충해야 함 - 국내 표준제정 포함 및 국제 표준화 활동 적극 참여 필요 - 소프트웨어 프로세스 개선과 품질 시스템 도입, 표준화 전문가 양성을 병행 - 소프트웨어 품질, 생산성 확보의 중요성 증대로 표준 활용도의 중요성 인식 확산 - 다수의 평가자가 관여되고 이들의 품질이해와 중요도 인식의 차이 극복이 필요함에 따라 평가의 객관성 보장을 위한 노력이 필요함 다. ISO 14598의 SW 아키텍쳐 측면의 평가방안

절차 내용 중점사항 품질 속성 도출 기능적 비기능적 요구사항 반영 비기능적 요구사항 : 보안, QoS, 성능 품질 속성 시나리오 작성 품질속성 TEST를 위한 시나리오 작성 비기능적 요구사항중심 도출 품질 속성 TEST 도출된 시나리오 기반 TEST 비기능적 품질 속성 TEST 품질 속성 평가 ATAM 모형을 이용한 TEST 결과에 대한 평가 수행

소프트웨어 테스팅 국제 표준, ISO29119의 개요 가. ISO29119의 정의
SW 개발 수명주기 전 과정에 걸쳐있는 테스팅 프로세스와 관련 산출물 표준 나. ISO29119의 필요성
소프트웨어 테스팅 체계 정립 및 테스팅과 품질에 대한 인식 개선
민간 De facto 표준(ISTQB)의 등장으로 혼란 가중 : 테스팅 표준 간의 호환성 마련
조직의 테스팅 수행 수준의 객관적 지표 수립 (Gaurantee level)
ISO 29119의 구성 및 프레임워크 가. ISO 29119의 구성

구분 설명 Part1 Concepts and Vocabulary 소프트웨어 테스팅 원리와 프랙티스의 개요, 테스팅 컨셉, 용어를 소개 Part2 Testing Process 소프트웨어 수명주기 프로세스 표준(ISO/IEC 12207)의 테스팅 관련 부분 준수 테스팅에 필요한 추가적인 Guidance 제공 Part3 Testing Documentation 테스팅 프로세스 파트와 연계된 표준적인 문서 템플릿 제공 Part4 – TestingTechniques 테스트 케이스 설계, 범위 측정, 인스펙션 등의 테스팅 기법에 대한 상세한 내용 수록

나. ISO 29119 프레임워크 - 전세계 산업계에 이미 퍼져서 사용되고 있는 IEEE829, IEEE1008, BS7925-1,2 등 기존의 혼재되어 있는 표준을 근간으로 집대성하여 산업계의 혼돈을 줄이고, 업계가 완성도 높은 테스팅을 할 수 있도록 지원하기 위한 목적으로 만들어지고 있음. 3. ISO/IEC 29119의 기대 효과 가. 동일한 제품 및 시스템 개발 비용으로 보다 높은 품질 수준 확보 나. 소프트웨어 테스팅 체계 정립, Guarantee level을 갖는 테스팅 수행 다. 테스팅과 품질에 대한 인식 개선, 테스팅 전문가 확보 및 동기부여, 툴을 활용한 표준 프로세스 구축

한국형 소프트웨어 평가모델 GS인증의 개요 가. GS(Good Software)인증의 정의
SW 품질평가 국제표준인 ISO/IEC 9126, 14598, 12119 등을 준용하여 개발된 SW 시험∙인증 서비스에 활용하고 있는 평가모듈
GS 인증은 ISO/IEC 9126이라는 국제표준을 근간으로 개발된 평가모듈을 사용하여 평가한다 그리고 평가 절차는 ISO/IEC 14598을 근간으로 한다
ISO 국제표준을 기준으로 SW의 기능성, 신뢰성, 효율성, 사용성, 유지보수성, 이식성, 성능, 상호운영성, 연동성 및 적합성을 시험 및 테스트하여 인증 나. GS인증 도입 배경 1) 국내 소프트웨어 업체의 영세성, 마케팅 능력 부족, 낮은 제품 인지도, 시장개척 어려움 2) SW업체를 중심으로 제품의 품질 향상을 위한 시험·인증제도의 국가적 도입 필요성 제기
GS인증 품질모델 및 시험∙인증절차 가. GS인증 품질모델

(9126의 품질평가모델 + 일반적 요구사항(식별 및 표시, 안전성) 추가) (9126의 각 품질모델에서 준수성 추가, 사용성에 "선호도"추가) 나. GS인증 시험∙인증 절차 1) 상담 및 계약 : 인증신청->시험범위/일정협의->�계약->�산출물/제품 제출 2) 시험 : 분석/설계->시험->결함발견 후 재시험->개선->�시험 반복 3) 결과보고 및 인증심의 : 보고서->인증심의위->�결과통보->�인증서 교부 3. GS인증 획득 시 기대효과 1) IT 측면 : 공인시험/인증통한 단기간에 SW제품의 획기적인 품질 개선 가능 2) 마케팅 측면 : 제품 신뢰성 제고 및 국제경쟁력을 확보, 인증 획득업체의 신뢰성 및 인지도 향상으로 마케팅 비용 절감, 매출의 증대 3) 경영 측면 : GS인증 제품 우선구매제도, 각종 법적 면제혜택 및 병역특례 심사 가산점, 제안 평가 가산점 부여 등 4. 제품설명서 평가를 위한 체크리스트 실 적용사례

SW기업이 GS인증을 획득하거나 발주기관이 GS인증제품을 구매하였을 경우의 혜택 가. 품질이 개선되고 비용 절감
제3자 시험인증을 통하여 단기간에 획기적인 품질개선과 비용 및 시간절감
SW BMT를 통한 국산제품의 우수성 부각 및 막연한 외산 SW 선호 사상 불식 나. 마케팅/홍보 용이
SW BMT를 통한 국산 제품의 우수성 부각
인증획득 제품에 대한 사이트(www.swit.or.kr) 홍보 게재 다. 다양한 제도적 혜택
GS인증제품 우선구매제도 시행
중소기업청 성능인증 시 성능검사 면제
저렴한 요율의 성능보험제도 및 공공기관 구매자 면책제도 시행
신SW상품대상 수상작 GS인증 의무화
정보화사업 발주 시 GS인증제품에 대한 SW분리발주 추진 명시

SW 산업 경쟁력 강화를 위한 SP 품질인증제도의 개념 가. SP(Software Process) 품질인증제도의 정의
SW 개발 단계별 작업절차와 산출물 관리 역량을 평가 인증하는 제도
5개 영역, 17개 평가항목으로 구성 나. SP 품질인증제도의 도입 배경

구분 개발 국내 SW 프로세스 개선활동 미비 SW 프로세스개선 비용 및 일정확보 어려움 SW 프로세스개선 전담전문 인력 및 기술인력 확보 어려움 해외 모델 도입에 대한 오버헤드 발생 해외 모델의 이해/적용위한 전문 인력 활용에 따른 비용 부담 긴 심사기간, 높은 인증비용, 민간 차원의 인증관리 한계점 정부 차원의 프로세스 역량 강화 정책추진 “SW 사업 관리감독에 관한 일반 기준” 제정 및 실시 해외 각국의 자체적 SW 프로세스 품질개선 노력 인도 : CMMi 기반 SW 프로세스 품질 인증지원, 홍보 미국 : 중소규모 조직의 품질향상 위한 지역별 센터 운영 멕시코 : 중소규모 조직을 위한 자체적인 평가 모델 개발

SP 품질인증제도의 구성 가. SP 품질인증제도의 품질인증 등급
개발, 지원, 프로젝트 관리 등 3개 영역의 수준이 인정되면 2레벨
개발, 지원, 프로젝트 관리, 프로세스 개선, 조직관리 등 5개 영역의 수준이 인정되면 3레벨 나. SP 품질인증제도의 품질인증 등급 별 특징

등급 조직 특징 1등급 프로젝트를 임기응변식으로 수행 프로젝트 구성원이 공유 할 수 있는 표준 프로세스가 없음 시행착오 해결 결과를 공유하지 못하여 개인 및 프로젝트팀 차원에서 같은 시행착오가 반복적으로 발생함 프로젝트 수행을 위한 프로세스 역량 개선이 필요한 수준을 의미 2등급 개별 프로젝트를 성공적으로 수행 프로젝트 차원에서 수립된 표준 프로세스에 따라 프로젝트를 수행하고, 그 결과는 프로젝트 팀 단위에서만 공유하고 관리함 동일한 시행착오가 프로젝트 팀 내에서는 반복적으로 발생하지 않으나 조직 차원에서는 반복적으로 발생함 3등급 대부분의 프로젝트를 안정적이고 일관되게 수행 조직 차원에서 업무 수행 방법을 조직 표준 프로세스로 수립하고, 개별프로젝트의 다양한 특성에 따라 조직 프로세스를 상황에 맞게 조정하여 적용하며 그 결과를 조직 전체가 공유함 시행착오의 반복적 발생이 조직 차원에서 방지됨 3. SP 품질인증제도 시행의 의미

관점 내용 국가 관점 S/W 중소기업에 대한 정부 지원책, 산업 활성화 방안 제시 해외 비용 지출의 절감, 국내 S/W 산업의 경쟁력 강화 방편 시장의 요구를 국가 차원에서 충족, Product 관점 GS인증과 연계 산업 관점 대기업 편중된 S/W 시장 개편 기회, 벤처 활성화계기 마련 고품질 S/W 확보, 전문 인력 양성, 프로세스 개선인식 전환 기업 관점 상대적 저렴한 비용, 짧은 기간 내 국내 S/W 프로세스 인증 획득가능 기업 내 개발 역량 강화, 내재화 통한 기업의 시장 신뢰성 확보 신규 시장 진출 기회, 중소기업 Brand 가치 제고 - CMMi, SPICE, ISO9000 등 기존 외국 표준 모델들을 대체 가능한 한국형 모델로 SW 산업의 제 2의 성장 동력마련, 향후 SW 시장의 글로벌 강자로 발돋움 초석 마련 ※ ISO9000 : 국제표준화기구(ISO)에서 제정한 품질경영에 대한 국제규격 4. SP 품질인증제도의 향후 활성화방안

저해요소 활성화 방안 단기간 평가 수행 평가의 신뢰성 저하, 제도의 오류 및 오용사례 우려 주기적 심사 통한 공정성 확보, 불법적 사례에 대한 처벌강화 인증 심사비용 부담 심사비용을 최소화 하였으나 중소기업에게 부담으로 존재 제도적 지원 방안 마련, 환급제도, 입찰시 가산점부여 국제적 인증문제 국내에서만 평가가 유효, 해외에서 활용할 수 없는 문제 봉착 향후 ISO15504, CMMi와 상호호환성 가질 수 있도록 개선 국내 모델의 해외 사업자 홍보 및 적정성 판단지원 평가인 수준관리 시행 초기 적정자격의 심사원부재, 장기간 심사대기 우려 조기 평가인 육성 체계 마련, 평가 절차의 표준화시도 조기 정착에 대한 부담 인증 유예기간 설정, 홍보 활동 통한 인식 전환유도

※ ISO15504(SPICE : Software Process Improvement Capability Determination) : 조직의 소프트웨어 개발 프로세스를 개선하고 개발자의 개발 능력을 향상시킴으로써 개발 위험을 통제

ISO/IEC 12207 유지보수 공정 개요
SDLC 표준인 ISO/IEC 12207에서 유지보수와 관련된 표준 공정
유지보수 공정은 유지보수자의 활동과 세부 업무를 포함
무결성은 유지하면서 현재의 SW제품을 수정하는 것을 포함
유지보수 공정은 SW 제품의 폐기로 종료됨
ISO/IEC 12207 유지보수 공정의 구성

구성 설명 착수 유지보수 요구사항에 따라 유지보수 계획과 절차 작성 문제 및 수정 분석 시스템의 유지보수 동안에 발생하는 문제에 대해 문제 및 수정사항을 분석하고 문서화 문제를 검증하고 수정사항을 처리하기 위한 대안 개발 수정 구현 변경사항 반영 유지보수 검토/수락 유지보수 결과로 수정된 시스템의 무결성 검토 유지보수 조치결과 완료에 대한 승인을 득함 전환 새로운 운영환경으로 이전, 계획수립, 영향 분석 폐기 시스템SW 폐기, 계획수립, 자료 보관 및 제공 3. ISO/IEC 12207 유지보수 공정의 특징 - 유지보수 공정을 표준화 하여 각 활동에서 어떤 작업을 수행해야 하는가를 정의 - 산출물 명칭, 내용을 규정하지 않고 조직 내에서 재정의 필요 - Plan-Do-See의 체계를 따름 - 문서화, 변경/형상관리, 통제 중시

소프트웨어 생명주기 표준 ISO12207 가. ISO12207의 정의
소프트웨어 생명주기 프로세스 기준으로 개념의 정의 단계에서부터, 폐기 단계까지 절차, 활동, TASK를 정의하는 표준 나. 소프트웨어 생명주기 표준 ISO12207의 필요성
조달자, 공급자 역할을 분명히 정의하여 양자간 계약 조달에 적합하게 개발
SW획득을 위한 개발, 공급, 운영의 전과정에 필요한 표준화된 언어 필요
예측가능 SW개발체계, 공학적인 개발과 관리지원으로 고품질의 소프트웨어 생산과 생산성 향상 방안 필요
ISO12207의 특징과 구성 가. ISO12207의 특징
SW산업계의 공통 프레임워크 관리하고, 제어 가능
비즈니스관계 당사자간 상호이해 촉진 시키는 의사소통 수단
과거 산출물 관리를 통한 지식의 활용과 축적 가능
SPICE(ISO/IEC 15504)는 ISO12207의 기본틀에 맞추어 개발됨(ISO12207은 "What"만이 정의됨) 나. ISO12207의 구성

구분 내용 기본 생명주기 프로세스 SW생명주기 동안 필요한 SW제품의 획득, 공급, 개발, 운영, 유지보수 지원 생명주기 프로세스 소프트웨어 프로젝트 성공을 위해 필요한 지원 프로세스 기본프로세스에 필요한 프로세스를 선정하여 수행 조직 생명주기 프로세스 조직에 대한 생명주기 프로세스와 인원에 대한 기본구조 구성운영 수행할 프로젝트에 맞도록 ISO12207 프로세스를 적용

ISO12207의 고려사항 및 기대효과 가. ISO12207의 고려사항
SW생명주기 도입함에 있어 ISO12207의 부록에 수록되어 제시된 TAILORING 프로세스를 도입하여 설정에 맞게 조정함
ISO12207 적용시 프로세스 심사모델인 SPICE(ISO15504)의 도입을 고려, 조직 프로세스 개선 기회를 도출, 프로세스 능력향상 나. ISO12207의 기대효과
정보시스템감리 프로세스의 표준화된 개념적인 큰틀을 제공
공급자와 사용자간 작업범위 명확한 분쟁의 조정이 가능함
프로세스의 큰틀에서는 ISO12207 적용, Best Practice로는 ITIL을 적용 가능함

프로젝트에 최적화된 개발을 수행하기 위한 개발 방법론 테일러링의 개요 가. 테일러링(tailoring)의 정의
기존의 개발 방법론에서 프로젝트에 최적화된 개발 방법론으로 절차, 활동 및 산출물을 변경하여 프로젝트 목적 달성을 위하여 방법론을 최적화하는 활동 나. 테일러링의 목적

구분 목적 관리측면 프로젝트 전략과 연계, 사용자 요구사항에 대한 최적화된 방법론 도출 최단기간, 안정적인 프로젝트 진행을 위한 사전 위험 제거 기술측면 프로젝트에 최적화된 기술요소 도입 프로젝트의 특성(방송SI, ISP, 유무선 통합 SI 등)에 맞는 최적의 산출물 및 도구/기법의 적용

개발 방법론 테일러링을 위한 구성도 및 기준 가. 개발 방법론 테일러링을 위한 구성도
프로젝트 특성, 사용자 요구사항, 프로젝트 팀원들의 기술 수준과 경험을 고려하여 프로젝트 품질관리자는 개발 방법론 Pool에서 최적화된 개발 방법론을 도출 나. 개발 방법론 테일러링을 위한 기준

구분 기준 설명 사업적 특성 업무 특성에 따라 대 고객접점 업무(Real Time 방법론) 데이터의 신뢰도가 중요시 되는 업무(DQM 방법론) 장비 설치 및 데이터 센터 이전 업무(H/W이전 및 설치 방법론) 재무적 특성에 따라 장기 투자가 필요한 업무(Spiral 방법론) 단기 투자가 필요한 업무(Agile 방법론) 프로젝트 특성 구성원의 경험에 따라 기술 수준이 낮은 경우(반복적/점증적 방법론) 기술 수준이 높고 경험이 많은 경우(waterfall) 프로젝트 일정에 따라 1년 미만인 경우 1년 이상인 경우 기술적 특성 고 난이도의 기술요구 품질보증 활동 강화(inspection, code review, testing) 웹 기반의 기술요구 시나리오 기반의 웹 Engineering기법 적용

※ DQM(Data Quality Management) : 데이터 품질 관리 3. 최적화된 방법론 도출을 위한 개발 방법론 테일러링 절차 가. 개발방법론 테일러링 절차

개발 방법론 POOL을 참조하여 Baseline 방법론을 도출
테일러링 지침을 참조하여 테일러링을 수행하여 Customized된 개발 방법론 도출 ※ 기준선(BaseLine)
기능기준선 : 타당성분석과 사용자 요구정의가 끝난 단계에서 설정된 관리기준선
할당기준선 : 모든 구성항목에 대한 성능요구사항을 정의하는 개발명세로 구성
제품기준선 : 구성항목에 대한 상세설계 문서에 의해 설정 나. 개발방법론 테일러링 사례
위의 Tailoring기준에 F, L, P, I 타입의 다양한 방법론이 존재함.
방법론 타입에 따라서 만들어야 하는 산출물의 종류가 약간씩 다름
방법론 타입을 기준으로 적용여부에 체크를 하여 해당하는 프로젝트의 방법론을 테일러링 함
개발방법론 테일러링시 주의사항 가. 반드시 PM 및 고객과 함께 테일러링 수행 나. 기존의 개발 방법론에서 반드시 필요한 산출물과 프로세스만 선택하여 수행 다. 필요 없는 산출물과 프로세스는 프로젝트 팀원에게는 부담 가중

I. 프로세스 관점의 품질경영시스템 국제규격 – ISO9000 가. ISO9000의 정의 - 국제화 표준화 기술위원회에서 제정한 품질경영과 품질보증에 관한 국제 규격 - 통상 활동을 원활히 하기 위해 ISO에서 제정한 공급자와 구매자 사이의 품질 경영과 품질보증에 대한 기준 나.ISO9000 인증의 필요성

관점 필요성 고객 관점 고객은 품질 시스템의 제 3자 인증을 통해 공급자 평가 가능 고객의 기대 요구를 반영하여 고객의 만족도 증대 가능 절차와 방법, 책임과 권한을 명확히 하여 투명성과 신뢰성 확보 가능 조직 관점 조직과 자원의 효율적 관리 가능 품질향상/불량 예방/낭비 제거 가능 안정성과 신뢰성 확보 가능 지속적인 개선으로 생산성과 능률의 향상을 기대 가능 변화 관점 국내외 환경 변화에 능동적, 효율적으로 대비 세계 각국에서 ISO9000 인증 요구 추세 완제품의 품질향상을 위해 모기업에서 협력 업체에 요구 국가 조달 물자 구매시 인증업체 우선 구매실시

II. ISO9000 인증의 목표 및 구성요소 가. ISO9000 인증의 목표

1) 프로세서를 기반으로 한 품질경영시스템의 지속적인 개선 2) 효율적인 경영자원 활용과 품질비용의 절감 3) 제품 질의 향상과 경쟁력 향상 4) 기업 대외 이미지의 향상 나. ISO 9000의 3대 요소 1) 투명성 : 인증은 투명성이 있어야 함 2) 원칙 : 인증 시 원칙을 준수해야 함 3) 국제 표준 : 각 기준 및 규격 등은 국제표준 준수 다. ISO 9000 인증 규격

구분 설명 ISO9000 품질경영시스템 기본 및 용어 ISO9001 품질경영시스템 규격 제품의 설계 및 서비스에 대한 품질보증 모델 ISO9002 제품의 검사 및 시험에 대한 품질보증 모델 ISO9003 최종 검사 및 시험에 대한 품질보증 모델 ISO9004 품질경영시스템 성과 개선 지침 품질 경영 및 품질시스템 요소에 대한 지침 품질경영시스템의 효과성과 효율성도 고려하는 지침 제공 조직의 성과개선과 고객만족 및 기타 이해관계자의 만족 ISO 9000-3 ISO 9001의 내용을 소프트웨어 산업에 적용한 모델

라. ISO9000(ISO9000:2000)의 8대 원칙

구분 설명 1. 고객중심 조직은 고객에 의존하고 있다 2. 리더십 리더는 조직의 목적과 방향의 일관성을 수립한다. 3. 전원참여 모든 계층의 사람들이 조직의 필수 요소이다. 4. 프로세스 접근 방법 관련된 자원 및 활동이 하나의 프로세스로 관리될 때 바라는 결과가 보다 효율적으로 얻어진다. 5. 경영에 대한 시스템 접근 방법 상호 연계된 프로세스를 하나의 시스템으로 파악하고 이해하며 관리하는 것은 조직의 목표를 효과적, 효율적으로 달성하는데 이바지 한다. 6. 지속적 개선 조직의 총체적인 성과에 대한 지속적 개선은 조직의 궁극적인 목표가 되어야 한다. 7. 의사결정에 대한 사실적인 접근 방법 효과적인 결정은 데이터 및 정보의 분석에 근거한다. 8. 상호 유익한 공급자 관계 조직 및 조직의 공급자는 상호 의존적이며, 상호 이익이 되는 관계는 가치를 창조하기 위한 양쪽 모두의 능력을 증진시킨다.

III. ISO9000 인증의 추진 절차 및 기대 효과 가. ISO9000 인증 추진 절차

나. ISO9000 인증 기대 효과 1) 상품/서비스 매출 증대 2) 품질 의식 제고 및 생활화로 품질 향상의 지속적 유지 3) 품질비용 절감 및 시간 절약 4) 기업의 인지도 및 신뢰도 향상과 기업 노하우 축적 5) 기업 내의 계층간, 부분간의 커뮤니케이션 증대 다. ISO9000 인증 시 직면하게 되는 문제점

문제점 해결책 ISO9000 인증 규격을 이해하는 이력 부족 인증 규격에 대한 내부 Study 강화 서구식 관리 방식에 의한 규격 요구사항의 이해 부족 외부 교육 기관/전문가 활용 인증 준비를 위한 기록 범위의 판단 선취득 기업의 사례 연구 전 직원 참가의식 부족 지속적인 사내 교육 및 변화 관리 활동 수행 프로젝트 담당자에게 지나친 집중 인증 취득에 관련된 비용 부담 경영층의 지원 획득 인증 취득 시 매출 증대와의 연계 방안 강구 QC활동 등 기존의 품질관리 활동과의 효율적인 연계 미흡 기존 품질관리 활동과 인증규격과의 Mapping 활동을 통한 업무 재활용 증대

코딩

코딩 단계의 로드맵
코딩 오류 가. 메모리 누수(Memory Leak)
정의 : 메모리가 해제 되지 않고 프로그램에 계속 할당되는 현상
짧은 프로그램에는 영향이 적지만 장기로 수행되는 시스템에는 치명적인 영향을 줌
메모리를 계속 할당되다가 메모리가 고갈되어 비정상적으로 정지
ex

char foo(int s) { char output; if(s > 0) output = (char*)malloc(size); if(s == 1) return NULL; // s가 1일인 경우 메모리 누수 발생 return(output); }

나. 중복된 프리 선언 - 정의 : 프리로 선언된 자원을 또 다시 프리로 선언하는 경우 - ex

int main() { char str; str = (char)malloc(10); if(global == 0) free(str); free(str); // global이 0인 경우 str이 메모리가 이중으로 해제 }

다. NULL의 사용 - 두 개의 변수가 동일한 객체를 참조하다가 하나가 프리 되었을때 다른 하나를 이용하여 접근을 시도하면 오류가 발생 - ex

char ch = NULL; if(x > 0 ) { ch = 'c'; } printf("%c", ch); // NULL 값 출력 *ch = malloc(size); ch = 'c';

라. 배열 인덱스 오류 - 배열의 인덱스가 한도를 벗어나면 예외 오류가 발생 - ex : i값이 80이 되면 한도 값 79를 벗어나 오버플로우 발생

dataArray[80]; for(i = 0; i <= 80; i++) dataArray[i] = 0;

마. 버퍼 오버플로우 - 프로그램 버퍼에 복사하여 입력받으려 할 때 입력 값을 고의로 아주 크게 주면 스택이 버퍼에 오버플로우가 발생 - ex

void mygets(char str) { int ch; while(ch = getchar() != '\n' && ch != '\0') (str++) = ch; } int main(){ char s2[24]; mygets(s2); }

바. 동기화 오류

종류 내용 데드락 다수의 쓰레드가 서로 자원을 점유하고 릴리즈 하지 않는 상태 다른 쓰레드가 점유하고 있는 자원을 또 다른 쓰레드가 기다리고 있는 경우 레이스 컨디션 두 개의 쓰레드가 같은 자원을 접근하여 수행 결과가 쓰레드의 실행 순서에 따라 다르게 되는 경우 모순이 있는 동기화 공유하는 변수를 접근할 때 락킹(Locking)과 언락킹(Unlocking)을 번갈아하는 상황에서 오류가 많이 발생

리팩토링(Refactoring) 가. 정의
소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부구조를 변경하는 작업
소프트웨어 모듈의 외부적 기능은 수정하지 않고 내부적인 구조, 관계 등을 단순화 하여 소프트웨어의 유지보수성을 향상시키는 기법
프로그램 코드 중 읽기 어려운 프로그램, 중복된 로직을 가진 프로그램, 실행중인 코드를 변경해야 하는 특별한 동작을 요구하는 프로그램을 찾아내어 성능과 코드의 구조 등을 개선을 시키는 과정 나. 목적

목적 내용 소프트웨어 디자인 개선 적절하지 않은 코드를 제거하고 구조가 망가지지 않도록 디자인을 유지하고 잘 파악되도록 바꿈 소프트웨어를 이해하기 쉽게 만듦 프로그램을 사용하거나 읽는 다른 사람이 있다면 프로그램을 쉽게 이해할 수 있음 버그를 쉽게 찾음 프로그램의 구조를 명확히 함으로써 프로그램에 대한 가설을 잘 세우고 그 진위를 빨리 파악하여 버그를 쉽게 찾음 프로그램을 빨리 개발 소프트웨어를 빨리 개발하려면 좋은 디자인 가장 중요하고 강력하게 영향을 미치는 요소 유지보수성 향상 코드의 단순화로 소스의 가독성 향상 유연한 시스템 소프트웨어 요구사항 변경에 유연한 대처 가능 품질향상 소프트웨어 오류 발견이 용이하여 품질향상

리팩토링 사례 가. 사례 1

수정 전 프로그램 수정 후 프로그램 int a, b, r[x][y]; for(a = 1; a <= x; a++) for(b = 1; b <= y; b++) r[a-1][b-1] = (a - 1) + (a - b)*(b -a); int a, b, r[x][y]; for(a = 0; a <= x; a++) for(b = 0; b <= y; b++) r[a][b] = a + (a - b) * (b -a);

나. 사례 2

수정 전 프로그램 수정 후 프로그램 void foo( char c ) { int i, count, len; char str[MAX]; cin >> str; len = strlen(str); count = 0; for(i = 0; i <= len; i++) if( str[i] == c) { count++; str[i] = '\n'; } count << str << " " << count << '\n'; } void foo( char c ) { int i, count, len; char str[MAX]; cin >> str; len = strlen(str); newfun(count, len, str, c); count << str << " " << count << '\n'; } newfun(int& count, int len, char* str, char c) { int i; count = 0; for(i = 0; i <= len; i++) if( str[i] == c) { count++; str[i] = '\n'; }

리팩토링 프로세스 및 주요기법 가. 리팩토링 프로세스
단일 리팩토링(소규모의 변경)
코드가 전부 잘 작동하는지 테스트
전체가 잘 작동하면 다음 리팩토링 단계로 전진
작동하지 않으면 문제를 해결하고 리팩토링 한 것을 Undo하여 시스템이 작동되도록 유지 나. 리팩토링 주요기법

기법 분류 내용 메서드 정리 Extract Method 그룹으로 함께 묶을 수 있는 코드 조각이 있으면, 코드의 목적이 잘 드러나도록 메서드의 이름을 지어 별도의 메서드를 추출 Replace Temp With Query 어떤 수식의 결과 값을 저장하기 위해서 임시변수를 사용하고 있다면, 수식을 추출해서 메서드로 만들고, 임시변수를 참조하는 곳을 찾아 모두 메서드 호출로 교체 객체간 기능 정리 Move Method 메서드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면, 이 메서드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메서드 생성 Extract Class 두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우 새로운 클래스를 만들어 관련있는 필드와 메서드를 예전 클래스에서 새로운 클래스로 이동 데이터 은닉 Encapsulation Field Public 필드가 있는 경우, 그 필드를 Private로 하고 접근자 제공 단순화 Rename Method 메서드의 이름이 그 목적을 드러내지 못하고 있다면 메서드의 이름 변경 일반화 다루기 Full up Field 두서브 클래스가 동일한 필드를 가지고 있다면 해당 필드를 슈퍼 클래스로 이동 Full up Method 동일한 기능을 하는 메서드를 여러 서브 클래스에서 가지고 있다면 슈퍼클래스로 이동 인터페이스 분리의 원칙(ISP) Extract Interface 클라이언트가 클래스의 어느 특정 기능만을 이용한다면 이러한 기능의 부분 집합을 별도의 인터페이스를 통해 추출

코드스멜과 리팩토링

코드스멜 설명 리팩토링 중복된 코드 기능이나 데이터 코드가 중복 중복제거 긴 메서드 메서드의 내부가 너무 김 메서드 크기 조정 큰 클래스 한 클래스에 너무 많은 속성과 메서드가 존재 클래스 몸집을 줄임 긴 파라미터 리스트 메서드의 파라미터 개수가 너무 많음 파라미터 개수를 줄임 두가지 이상의 이유로 수정되는 클래스(Divergent Class) 한 클래스의 메서드가 2가지 이상의 이유로 수정이 되면, 그 클래스는 한 가지 종류의 책임만을 수행하는 것이 아님 한가지 이유만으로 수정되도록 변경 주석(Comments) 코드를 이해할 수 없기 때문에 주석처리를 함 주석이 없어도 코드를 이해할 수 있도록 코딩

리팩토링 기대효과 및 고려사항 가. 기대효과
품질 측면 : SW품질 향상
생산성 측면 : 개발 생산성 증대
비용 측면 : 유지보수 비용 절감 나. 고려사항
코드에 대한 Inspection 기법을 통해서 프로그램뿐만 아니라 설계 문서 등에서 문제가 있는지를 먼저 살펴보도록 함
프로그램을 실행시키지 않고 정적 분석을 통해 코드의 결함이 있는지 찾아내도록 함
코드스멜에 대해서 사람이 직접 소스를 검증하지 않고 자동화된 Tool에 검증할 수 있도록 Inspection 자동화 도구를 지속적으로 발전시킬 필요가 있음
아키텍처, 모델링 관점, 디자인 패턴 중심 접근, 단계적 수행
구조적 변경 후 회귀테스트로 확인, 리팩토링 지원도구, 백업도구 활용

코드 인스펙션 가. 정의
프로그램이 성공적으로 컴파일 되고 정적 분석 도구에 의하여 검사된 후에 이루어짐
컴파일러나 정적 분석기가 자동으로 찾아낼 오류들을 사람이 찾는 노력과 시간을 절약하기 때문 나. 목적
코드에 묻혀있는 결함을 찾아냄
효율성, 코딩 표준의 준수 여부 등을 검사
코드 인스펙션 결함 타입 구별 가. 로직 문제 : case 또는 setup이 빠짐, 중복 로직 조건이 빠진 경우, 불필요한 기능, 잘못된 해석, 잘못된 조건 테스트, 틀린 변수의 체크, 반복 루프의 결함 나. 컴퓨팅 문제 : 잘못된 수식, 오차, 부호 오류 다. 인터페이스/타이밍 문제 : 인터럽트 처리 부정확, I/O 타이밍 부정확, 서브루틴/모듈 불일치 라. 데이터 처리 : 초기값 부정확, 데이터 접근 저장 부정확, 자료 값의 스케일 또는 단위 부정확, 벡터 데이터의 차원 부정확
코딩 단계에서 코드 인스펙션을 위한 체크리스트

인스펙션 대상 체크항목 클래스 전체 C1. 클래스의 이름은 적절한가? 요구분석이나 설계와 일치하는가? 충분히 세분화/일반화 되었는가? C2. 추상화될 수 있는가? C3. 헤더주석이 목적을 잘 나타내고 있는가? 헤더주석이 관련된 요구나 설계요소를 언급하고 있는가? C4. 소속된 패키지를 기술하였는가? C5. 충분히 private인가? Final이 되어야 하는가? C6. 문서표준이 적용되었는가? 속성 A1. 속성이 필요한가? A2. static이 될 가능성은? 모든 인스턴스가 이 변수를 가져야 하나? A3. final이 되어야 하나? 값이 변경되는가? get메서드만 필요하지 않은가? A4. 명명규칙이 적절히 적용되었는가? A5. 충분히 private인가? A6. 속성들이 가능한 독립적인가? 생성자 CO1. 생성자가 필요한가? CO2. 모든 속성을 초기화하는가? CO3. 충분히 private인가? CO4. 상속된 생성자를 적절히 사용하였는가? 메서드 헤더 MH1. 메서드 이름을 적절히 잘 정하였는가? MH2. 충분히 private인가? MH3. static이 될 수 있는가? MH4. final이 되어야 하는가? MH5. 헤더주석이 메서드의 목적을 잘 나타내고 있는가? MH6. 메서드 헤더주석이 관련되는 요구와 설계를 언급하고 있는가? MH7. 모든 필요한 변경조건을 잘 기술하였는가? MH8. 파라미터 타입이 제한되어 있는가? 메서드 내부 MB1. 알고리즘이 상세 설계와 일치하는가? MB2. 코드가 전제조건만을 가정하고 있는가? MB3. 결과조건의 모든 것을 만족하고 있는가? MB4. 코드가 요구한 불변조건을 잘 지키고 있는가? MB5. 반복구조가 모두 종료되는가? MB6. 요구하는 표준 표시법을 따르고 있는가? MB7. 코드가 정확한 타입을 리턴 하는가?

가. 정적 기법(Static Techniques) 정의 - 프로그램을 실행하지 않고 테스트 나. 정적 기법 종류

종류 설명 리뷰(Manual Review) 사람이 문서를 기반으로 검토하는 것으로 얼마나 공식적이냐에 따라 Inspection, Technical Review, Walkthrough, Informal Review로 나누어짐 자동화 영역이 아님 정적 분석(Static Analysis) 자동화의 영역이고 이를 지원하는 도구를 정적 분석 도구라고 함

정적분석(Static Analysis) 가. 정의
프로그램 테스트를 조직적으로 분석하여 결함 찾아냄
소프트웨어 도구를 이용하여 자동으로 분석 나. 목적
오류나 잠재적인 오류를 찾아내고 디버깅에 유영한 정보를 생성
정적분석방법 가. 코드에 존재하는 결함으로 나타날 비정상적인 패턴이나 원하지 않는 패턴을 찾는 방법
비정상적인 패턴을 찾는 방법 : 자료흐름 분석, 논리흐름 분석
자료흐름 : 자료가 어디서 정의되고 어디서 사용되었는지를 나타내는 그래프
자료변칙(data anomaly) : 자료 흐름도를 분석하여 자료가 정의되지 않고 사용되거나 정의되고 사용되는 비정상적인 패턴을 찾음
실행할 때 프로그램의 버그를 일으킬 코드 상에 존재하는 결함을 직접 찾는 방법

가. 정적분석 도구 정의 - 프로그래밍 언어(C, C++, Java 등)로 작성된 소스코드를 프로그램의 실행(Execution)없이 분석용 파서(Parser) 또는 분석 엔진 등을 통하여 소스코드의 품질 및 예측 가능한 SW 결함을 리포팅 하는 분석 도구 나. 정적분석 도구 종류 - 소스코드 품질 분석도구 : 결함 보다는 소스코드의 복잡도(Cyclomatic Complexity, Halsted Complexity 등)나 기타 SW 분석 자료(함수 호출 관계, 함수 호출 중첩도, 변수 참조, Line 수, Comment 수 등)의 정보를 얻을 수 있음 - 룰 기반 분석도구 : 소스코드를 라인단위로 분석하여 일정한 룰 (MISRA, CWE등)을 적용하여 위반시 위반 사례를 리포팅 - 의미 분석 기반 도구

테스트

오류(error), 결함(fault), 고장(failure)의 의미 가. 오류(error)
프로그램의 실행결과가 예상한 결과와 다를때 그 차이를 의미
코드가 실행되어 관찰된 값과 명세에 기록된 이론적으로 올바른 값과의 차이
소프트웨어가 결함을 갖게 하거나 고장을 일으키게 한 인간의 실수 나. 결함(fault)
시스템이 요구된 기능을 수행하지 못하게 하는 조건
버그(bug)라고도 불리는 것으로 소프트웨어의 오작동의 근본 원인 다. 고장(failure)
시스템이나 컴포넌트가 명세로 작성된 요구와 기능을 제대로 수행할 수 없음을 의미
소프트웨어의 실행 동작이 명시된 동작과 차이가 난다면 고장을 일으킨 것임
단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스트, 설치 테스트, 리그레이션 테스트

테스트 단계 정의 단위(컴포넌트) 테스트 (Unit test)/ 모듈 테스트(Module test) 컴파일된 독립 모듈의 완전성 테스트 모듈의 결함여부를 테스트 대부분 모듈을 구현한 프로그래머가 테스트 실시 분리된 기능에 대한 검증으로 단위 테스트 프레임워크를 이용하여 개발자가 테스트 목적 : 모듈을 정확하게 구현, 예상한 기능이 제대로 동작하는가 점검 통합 테스트 (Integration test) 모듈을 결합하여 하나의 시스템을 만드는 테스트 모듈을 결합하여 모듈간의 인터페이스의 오류를 테스트 전체 시스템을 이루는 모듈을 모아 통합적으로 테스트 단위 테스팅보다 더 엄격히 시행되어야 하고 시험 기록이 잘 보존되어야 하며 발견된 오류는 철저히 기록 컴포넌트간의 상호 작용에 대한 검증으로 테스트 입력 값을 만들어 실행한 후 결과를 확인 목적 : 시스템이 요구된 기능을 제대로 수행하는가를 점검, 모듈 사이의 인터페이스를 시험 시스템 테스트(System test) (완성된 제품에 대한 테스트) 통합된 시스템의 테스트 소프트웨어의 기능뿐만 아니라 비기능적인 속성(예 : 신뢰성, 견고성, 성능, 안전성 등)도 만족되는 지를 검사 전체 시스템 동작에 대한 검증으로 암복호화 데이터의 처리결과 확인, 데이터의 처리시간을 통해 시스템 속도 측정, 정확한 데이터 처리 확인, 성공률과 실패율 확인 목적 : 시스템이 사용될 준비가 되었음을 알리는 테스트 인수 테스트(Acceptance test) (완성된 제품에 대한 테스트) 사용자가 수용할 만한 품질을 갖추었는지 여부를 테스트 사용자 요구사항 처리에 대한 검증으로 사용자가 요구기능을 입력하고 기능이 정확하게 수행하는지 확인 목적 : 사용될 환경에 설치하여 사용자 직접 사용하여 테스트 설치 테스트(Installation test) 현장에 시스템을 설치하여 가동시켜 보면서 하는 테스트 리그레이션 테스팅 (regression test, 회귀 테스팅) 시스템이 설치된 후 유지보수 단계에서 이루어지는 테스팅 작업 수정이 이루어진 부분과 그에 의한 영향을 시험해 보는 작업 예상된 수정과 통합이 되었는지를 확인하는 반복 테스트

테스트 작업 과정

가. 방법 결정 : 검사, 증명, 블랙박스 테스팅, 화이트 박스 테스팅, 자동화 도구 등 나. 테스트 케이스 선택 : 테스트 자료나 실행될 조건 다. 테스트 케이스 작성 : 올바른 결과를 미리 예상하여 작성하여 테스트 - 테스트 오라클(Test Oracle) : 모든 테스트 케이스를 위한 예상된 결과, 테스트 대상의 실제 결과와 비교할 목적으로 예상 결과를 결정하는 근거 - 테스트 케이스 예시

고유번호 테스트 대상 테스트 조건 테스트 데이터 예상 결과 FT-1-1 로그인 기능 시스템 초기화면 정상적인 사용자 ID와 패스워드 시스템 입장 FT-1-2 로그인 기능 시스템 초기화면 비정상적인 사용자 ID와 패스워드 로그인 오류 메시지 ..... ..... ..... ..... .....

라. 테스트 실행 : 테스트 케이스로 실행 - 테스트 하니스(Test Harness) : => 시스템의 일부 기능만 시험하기 위하여 소프트웨어에 변경을 가하는 경우 사용 => 부분적인 테스트를 위하여 코드에 삽입하는 프로그램 => 시스템을 테스트하기 위하여 작성된 별도의 프로그램 => 테스트가 끝난 후에 삭제되는 프로그램 4. 테스트 단계와 소프트웨어 개발 단계의 관계

화이트 박스 테스트와 블랙박스 테스트 비교

항목 화이트 박스 블랙박스 개요 내부 구조 위주 시험 기능 및 I/O 위주 테스트 검증 기준 test coverage 1) statement coverage: 소스코드의 모든 문장을 한번 이상 수행 2) decision coverage: 선택 조건의 모든 경우가 적어도 한번씩 테스트 3) loop coverage: 루프 구조를 완벽히 테스트 동치분해(등가분할, equivalence partitioning) 최소 3개의 클래스가 존재 1) 범위 내의 값(정상) 2) 범위 보다 작은 값(비정상) 3) 범위 보다 큰 값 (비정상) 단계 단위 테스트 통합 테스트, 시스템 테스트 공통 테스트를 통한 품질향상

● 등가분할(Equivalence Partitioning) 소프트웨어나 시스템의 입력값은, 입력의 결과로 나타날 결과값이 동일한 경우, 하나의 그룹으로 간주될 수 있다. 그리고 이러한 그룹 내의 입력값은 내부적으로 같은 방식으로 처리됨을 가정한다. 동등분할은 이러한 원리를 이용하여, 입력값/출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가집합의 원소 중 대표값 하나를 선택하여 테스트 케이스를 선정하는 것이다. 이 기법은 가능한 모든 경우의 수에서 테스트 개수를 줄여준다. [예제] A라는 학교에서 학생들의 성적에 따른 등급을 자동으로 계산해 주는 프로그램을 만들고자 한다. 100~90점은 A, 89~70점은 B, 69~50점은 C, 49점 이하는 D로 산정하고자 한다. 이때 등가분할에 의거한 데이터는 100<=점수<=90, 89<=점수<=70, 69<=점수<=50, 점수<=49로 총 4개의 데이터가 산출될 수 있다. 이것은 최소한 결과의 값을 선택하여 테스트를 수행한다는 것까지 보장한다. 6. 테스트 유형의 Validation과 Verification, Certification 차이점 가. Validation(확인) - 목적 : Are we building the right product? (올바른 제품을 만들고 있는가?) - 고객의 요구를 분석자가 정확히 파악했는지 검사하는 절차 - 사용자 시각으로 올바른 소프트웨어가 개발되었는지를 입증하는 과정 - 어느 단계의 개발제품이 최초의 사용자 요구 또는 소프트웨어 요구에 적합한지를 입증하기 위한 활동 나. Verification(검증) - 목적 : Are we building the product right?(제품을 올바르게 만들고 있는가?) - 제품이 설계에 맞게 만들어지고 있는지 또는 명세서를 충족하는가를 검사하는 절차 - 개발자 혹은 시함자의 시각으로 소프트웨어가 명세화된 기능을 올바로 수행하는지 알아보는 과정 - SDLC에서 어느 단계의 산출물이 이전 단계에서 설정된 개발규격과 요구들을 충족시키는지 여부를 판단하기 위한 활동 다. Certification (공인) - 사용자 혹은 사용자를 보호하는 입장의 전문가가 SW 품질을 공식적으로 확인하는 것 7. 소프트웨어 테스트 분류

테스트 영역별(목적) 테스트 항목

테스트 영역(목적) 테스트 항목 내용 기능 테스트 (Function test) 주어진 입력에 대해 기대되는 출력이 제공되는지 테스트 인터페이스 테스트 내부 시스템 I/F 프로젝트 개발 범위 내의 시스템 간 인터페이스의 트랜잭션 처리가 적정한지 점검 외부 시스템 I/F 외부기관 시스템과의 인터페이스에 의한 트랜잭션 처리가 적정한지 점검(KITTI, KBSi) 보안 테스트 권한시험 시스템의 접근권한이 적절히 부여되었는지 점검 Audit 기능 시험 시스템의 사용자 접근 기록, 관리기능의 적정성을 점검 성능 테스트 (Performance test) 응답속도, 처리량, 메모리 관리 능력, 처리속도 등을 테스트 구조 테스트 (Structure test) 소프트웨어에 내재되어 있는 논리 경로의 복잡도를 평가 모듈 테스트, 통합 테스트 및 시스템 테스트에 광범위하게 적용되는 테스트 스트레스 테스트 (Stress test) 과다한 정보 거래량이 부과되거나, 최저 조건 미달 혹은 최고조건 초과의 상황, 물리적인 충격이나 변화 시의 반응정도로 신뢰성을 테스트 - 시험을 시험목적에 따라 분류해보면, 주어진 입력에 기대되는 출력을 제공하느냐를 시험하는 (기능)시험과, 응답시간이나 처리량, 메모리 활용도 그리고 처리속도 등을 시험하는 (성능)시험이 있으며, 과다한 거래량이 부과될 때 최저 조건에 미달되고 최고 조건을 초과할 때 또는 물리적인 충격이나 변화에 대한 반응 정도로 신뢰성을 시험하는 (스트레스)시험, 그리고 소프트웨어에 내재되어 있는 논리경로(path)의 복잡도를 평가하는 (구조)시험이 있다 9. 테스트 단계별 영역의 효과적인 점검 시기

테스트 영역 테스트단계 단위 테스트 통합 테스트 시스템 테스트 인수 테스트 기능테스트 (기능성, 사용성, 신뢰성) ○ ○ ○

성능 테스트

○

○ 인터페이스 테스트

○

스트레스 테스트

○ ○ 보안 테스트

○

개발단계에서 소프트웨어 모듈의 기능성 확인을 위한 단위 테스트 개요 가. 단위 테스트 정의
모듈 테스트 또는 컴포넌트 테스트라고도 하며 프로그램 내의 각 서브프로그램, 서브루틴, 또는 프로시저, 클래스, 오브젝트 등 프로그램의 최소 구성단위를 테스트 나. 단위 테스트 특징
화이트박스, 블랙박스 테스트를 모두 적용할 수 있지만 일반적으로 화이트박스 테스트 기법을 적용함
디버깅 작업이 쉬움
병렬 처리가 가능하기 때문에 여러개의 모듈들을 동시에 테스트할 수 있음 다. 단위 테스트(Unit Test) 목적
소프트웨어 모듈, 서브루틴의 사용자 요구사항에 대한 단위 모듈을 테스트하기 위한 단계
단위 테스트를 통하여 모듈의 오류가 없음을 확인 라. 단위 테스트 단계의 주요 산출물 및 용도 1) 단위 테스트 계획서 : 테스트 범위, 일정, 담당자, 보고방법, 성공요소, 실패요소 2) 단위 테스트 케이스 : 각 모듈에 대한 테스트 케이스, 예측값, 결과, 결함여부 3) 결함보고서 : 단위 테스트 시에 발생된 결함내용, 심각도, 영향도, 수정여부 등 제시
단위 테스트 환경
단위 테스트 기법 및 테스트 전략 가. 단위 테스트 기법
인터페이스 테스트 : 정보 입∙출력의 적절성 시험, 파일속성, 입력 및 출력 매개변수, 요구되는 입∙출력I/O 테스트
지역 데이터 구조(자료구조) 테스트 : 모듈이 실행되는 동안 자료의 무결성 유지 여부를 시험, 자료형태, 변수 초기화, 자료형태의 일관성 테스트
경계조건 : 처리를 제한하거나 금지시키기 위해 설정된 경계에서 모듈의 적절한 작동 여부를 시험
독립경로 : 모듈의 모든 문장은 적어도 한번 실행됨을 확인하기 위한 시험
실행경로 테스트 : 다른 자료형태 간 비교, 잘못된 루프문 테스트
에러 핸들링 경로(오류처리) 테스트 : 오류처리 경로, 오류 메시지의 이해용이성, 오류 메시지의 상세정보 제공여부 테스트 나. 단위 테스트 전략

전략 블랙박스 화이트 박스 정의 사용자 관점의 I/O 테스트 개발자 관점의 Logic 테스트 장점 테스트 용이성 오류에 빠진 Feedback 단점 내부 연관도의 파악이 어려움 누락된 Logic 찾기 어려움 종류 동등분할, 경계값, 원인결과 등 구조, 루프 테스트

● 경계값 분석(Boundary Value Analysis) Partitioning을 이용하여 입출력 도메인을 equivalence class로 나누었을 때, 각 범위의 경계 값에서 결함이 발생하는 경우가 많다는 사실에 착안하여, 결함 검출 가능성을 높일 수 있도록 테스트 케이스를 설계하는 기법이다. 즉, equivalence class 안에서 테스트 케이스를 선정할 때, 임의의 데이터를 이용하는 것 대신에 class의 경계에 있는 데이터를 이용한다. 이 방법의 경우, 입출력의 수많은 변형이 존재할 수 있기 때문에 많은 수의 테스트 케이스를 요구 받게 되므로, 각 입력 변수를 위해 최소한 9개의 테스트 케이스를 선정해야 한다. 또 복잡한 계산을 요구하는 문제의 경우 equivalence class의 범위를 정의하는 것이 어려우므로 가능한 한 상세한 요구명세가 필요하다는 제한이 있다. [예제] 조건이 a≤ X₁≤b 이고, c≤ X₂≤d 일 때, 각 범위의 경계값을 분석하여 아래와 같이 입력값을 산정할 수 있다.

단위 테스트 고려사항 및 다른 테스트 단계와 관계 가. 단위 테스트는 개발자가 개발한 모듈의 이상여부를 검증함 나. 단위 테스트 시에 각 테스트 케이스의 도출과 각 테스트의 커버리지 계산이 중요 즉, 테스트에 제외되는 모듈의 로직을 최소화하여 테스트 수행 다. 단위 테스트시 블랙박스 테스트와 화이트박스 테스트의 결합형태 그레이박스 테스트를 통하여 중요모듈은 화이트박스로 하고 전체적으로 I/O중심의 블랙박스를 수행 라. 단위 테스트 완료후 모듈간의 통합 테스트와 성능, 보안, 강도, 사용자 인터페이스 테스를 위한 시스템 테스트 및 사용자가 직접 테스트를 수행하는 인수 테스트를 수행함 ※ 단위 테스트
문장 검증기준
선택 검증기준
경로 검증기준

문장검증기준: 1, 2, 3, 4, 5 선택검증기준: 1, 2, 3, 4, 5 1, 3, 5 경로검증기준: 1, 2, 3, 4, 5 1, 3, 5 1, 2, 3, 5 1, 3, 4, 5

※ 검증기준 종류

종류 내용 문장 검증기준 모든 문장이 한번씩 수행 되도록 검증하는 기준 예제 : 1-2-3-4-5-6-7선택 검증 기준 선택 검증기준 경로에서 나타나는 모든 분기점을 파악 두 개의 분기점에서 참과 거짓 모두 테스트 예제 : 1-2-3-4-5-6-7, 1-2-4-5-6-1 경로 검증기준 수행 가능한 모든 경로를 검사 예제 : 1-2-3-4-5-6-7, 1-2-3-4-5-6-1, 1-2-4-5-6-7, 1-2-4-5-6-1 조건 검증기준 IF 문장, While 문장 안에 있는 조건을 조사하는 기준 예제 : if(x>10 OR y<1)은 경우 x>10 경우와 OR y<1 모든 경우를 테스트

※ 단위 테스트 유형 - 개별적으로 테스트할 수 있는 소프트웨어 기능만을 분리하여 검증하며, 일반적으로 코드 접근을 허용하고, 디버깅 도구의 지원 하에 실행한다.

통합 테스팅(Integration Test) 가. 목적
시스템을 구성하는 모듈의 인터페이스와 결합 테스트
시스템 전체의 기능과 성능을 테스트
성능 테스팅 : 여러 기능을 수행하는데 소요되는 시간을 잼 나. 종류

종류 내용 비점전적 테스트 동시식(big-bang) 시스템을 구성하는 모듈을 각각 따로 구현하고 전체 시스템을 단번에 묶어 테스트 초보 프로그래머들이 사용하는 방법 ● 모든 모듈을 한꺼번에 통합하여 테스트 ● 단위 테스트에 많은 시간이 필요 ● 시스템의 중요 부분과 부수적인 부분을 구별하지 않음 점증적 통합 하향식 통합 테스트 (Top-down) 명령어 처리 모듈을 먼저 구현하고 테스트 명령어 처리 모듈 : 시스템 구조도의 최상위에 있는 모듈 하위층의 모듈로 내려가면서 테스트하고 추가하여 전체 시스템이 모두 결합될 때까지 진행 ● 주요 제어 모듈은 테스트 드라이버로 사용되고, 스텁은 주요 제어 모듈에서 직접 종속되는 모듈로 교체 ● 깊이 우선 또는 넓이 우선의 선택적 통합 접근법을 정하고, 하위 스텁은 실제 컴포넌트들로 한 번에 하나씩 대체 ● 테스트들은 각 컴포넌트가 통합됨으로써 수행 상향식 통합테스트 (bottom-up) 시스템 구조도의 최하위층에 있는 모듈을 먼저 구현하고 테스트 상위 모듈을 계속 더해 가면서 전체 시스템 통합 ● 하위 수준의 컴포넌트들을 특별한 소프트웨어 보조 기능을 수행하는 클러스터로 결함 ● 입/출력 테스트 케이스를 통합하기 위해 테스트 드라이버 사용 ● 클러스터가 테스트 됨 연쇄식/혼합식 통합 테스트 (threads/Sand쟈초) 특수하고 중요한 기능을 수행하는 최소 모듈 집합을 먼저 구현 보조적인 기능의 모듈은 나중에 구현하여 테스트한 후 계속 추가 ● 하향식 통합 전략과 상향식 통합 전략을 절충한 방식 ● 우선적으로 통합을 시도할 중요 모듈들을 선정한 후, 그 모듈을 중심으로 통합

점증적 통합 : 시스템의 일부가 구현되고 단위 테스트된 뒤에 부분적으로 통합하여 테스트, 단위 테스트가 끝난 모듈들을 단계적으로 추가 통합하여 테스트하는 방법
필요 소프트웨어 가. 스터브(stub)
테스트 대상 모듈을 호출하는 간이 소프트웨어
모듈에서 매개 변수를 전달 받어 단순한 메시지를 출력하거나, 랜덤 번호를 만들거나, 상수값을 돌려보냄
일정시간 동안 루프를 수행하거나, 입력값을 요구하고 다시 모듈로 돌아가게 함
하향식 통합 테스트에 사용
드라이버 보다 쉽게 작성 가능

나. 테스트 드라이버(driver) - 테스트 대상 모듈을 호출하는 간이 소프트웨어 - 매개 변수를 전달하고 모듈을 수행한 후에 나오는 결과를 보여줌 - 상향식 통합 테스트에 사용

다. 테스트 하니스(harness) - 시스템을 테스트하기 위하여 작성된 별도의 프로그램 - 테스팅이 끝난 후 삭제 3. 동시식 통합(Big-bang) 가. 한번에 중요부분 구분 없이 통합 테스트 나. 오류를 발견하는데 문제가 발생 - 시스템을 이루는 모듈들이 한꺼번에 테스트되므로 오류의 위치와 원인을 찾기 어려움 다. 단위 테스트에 많은 시간이 필요 - 각 단위 모듈을 위한 드라이버 및 스터브를 모두 마련 - 테스트 하니스 오류 가능성이 많음(완성된 후에 버려야 할 코드이므로 신중을 기하지 않음) 라. 중요한 부분과 부수적인 부분을 구별하지 않음 - 복잡하고 다른 모듈을 제어하는 중요한 기능을 하는 모듈은 오류가 있을 확률이 많음 - 복잡하고 중요한 부분 먼저 통합 테스트 한 후에 부수적인 부분도 구현하여 테스트 - 다른 모듈이 추가되면 시스템의 중요 부분은 다시 반복하여 테스트하여 이중작업 발생 마. 일정계획에 융통성이 없음 - 모든 모듈이 구현되고 테스트되기 전에는 통합 테스트를 시작할 수 없음 4. 하향식 통합(top-down) 가. 정의 - 시스템 구조도의 위층에 있는 모듈부터 아래층의 모듈로 내려오면서 통합되는 방법 나. 장점 - 점증적인 통합 형태이므로 하드웨어 사용이 분산되고 오류의 원인을 찾아내기 쉬움 - 상위층의 모듈을 먼저 테스트하므로 시스템의 계층 구조와 상위층의 중요한 인터페이스를 조기에 테스트 - 스터브의 사용으로 시스템의 모습을 사용자에게 일찍 보여줌 - 프로그래머가 많이 사용(작동되는 시스템에 대한 확증을 유지) 다. 단점 - 입출력을 수행하는 모듈이 대부분 최하위에 존재하므로 마지막에 가서야 통합 - 상위층에서는 테스트 케이스를 쓰기가 어려움 - 중요한 기능을 수행하는 최하위층 모듈은 충분한 테스트가 힘듦 5. 상향식(buttom-up) 통합 가. 정의 - 최하위 모듈을 먼저 통합하여 테스트하는 방법 - 다음 위층의 모듈을 추가하여 서브시스템을 계속 크게 만들어 나가는 방법 나. 장점 - 오류발견이 쉽게 하드웨어 사용을 분산 - 하위층에 중요한 기능의 모듈이 많은 경우 적당 다. 단점 - 테스트 초기에 시스템의 뼈대가 갖추어지지 않음 - 시스템의 모든 계층을 마지막에 가서야 확인 가능 - 사용자(개발 의뢰자)에게 시스템을 사용해 볼수 있는 기회를 충분히 제공하지 못함 6. 연쇄식(threads) 통합 가. 정의 - 입력, 출력, 어느 정도의 기본 기능을 수행하는 모듈들로부터 통합 테스트 - 연쇄식 : 특정 기능을 수행하는 모듈의 최소 단위(thread) 나. 장점 - 초기에 시스템의 골격을 보여주고 사용자의 의견을 빨리 수렴 - 대규모 시스템의 경우 초반은 시스템의 주요 기능만 수행하고 추후 부가적인 기능을 첨부(프로그래머의 수준을 향상시킴) - 시스템이 여러 프로그래머에게 나누어 개발될 수 있고 각 프로그래머도 시스템의 부분적인 개발 진도를 확인 가능 7. 통합 테스트 고려사항 - 테스트 작업을 위하여 작성되어야 할 테스트 하니스(test harness) 필요 - 테스트 드라이버(driver) 및 스터브(stub)의 양 고려 - 시스템의 중요한 모듈의 위치, 하드웨어의 가용성, 일정 등을 고려

시스템 테스팅(System Test) 가. 정의
개발 프로젝트 차원(범위)에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트
실제 최종 사용 환경 또는 이와 유사한 환경에서 수행 나. 시스템 테스팅 종류
기능 요구사항 : 기능 테스팅
비기능 요구사항 : 구조 테스팅, 성능 테스팅, 스트레스 테스팅,
구조 테스팅(화이트 박스 테스팅) 가. 단위 테스트에서 사용하는 화이트 박스 테스트와 동일
각 모듈의 입력, 출력 매개 변수
유틸리티 호출을 포함한 모든 모듈의 호출 나. 구조도에 있는 모든 경로와 서브 시스템간의 호출관계를 점검
모든 모듈이 적어도 한 번씩 호출되는지, 적당한 모듈에 의하여 호출되는지 검사 다. 테스트 케이스를 작성하기 위하여 처리 흐름도(transaction flow diagram) 사용
처리 : 특정 입력 클래스와 관련된 작업의 집합
작업 : 입력의 처리와 결과의 출력으로 구성 라. 처리 흐름도
처리와 관련된 작업 단계의 순서를 표현
자세한 논리적 처리는 보여주지 않고 입력에 대하여 어떤 일이 일어나는지를 나타냄
처리 과정 중에 호출되는 모듈을 리스트나 도표로 나타냄 마. 테스트 케이스를 작성하고 각 모듈의 입출력 매개 변수를 조사하며 모듈 내부와 호출을 자세히 검사
기능 테스팅(블랙박스 테스팅) 가. 정의
요구분석에 나타난 사항이 제대로 구현되었는지 테스트하기 위한 방법 나. 테스트 케이스를 작성할 때 시스템 구조 등의 내부 지식은 사용하지 않고 사용자 매뉴얼을 사용 다. 시스템 전체가 하나의 블랙박스이므로 단위 테스팅에서 사용하던 테스트 케이스와는 다름 라. 어떤 모듈이 호출되는가를 예측하고 조사할 필요 없으므로 입력과 출력에 대한 예상과 결과를 비교 마. 의사결정표(기능 테스팅 방법)
입력을 클래스로 나누고 각 클래스에 대한 결과를 나타냄
사례

대금지불 지불 x x

미지불

x x 완불 완불 x

미완불

x 영수증 우송 O O

대금 청구서 우송 O

상품 안내서 우송

스트레스 테스팅 가. 정의
과다한 입력을 주었을때 시스템이 어떻게 처리하는가를 테스트 나. 자료구조나 파일이 충분히 처리할 수 있도록 설계되었는지 점검 ※ 시스템 테스트 유형
소프트웨어 시스템의 특정 요구 사항을 완벽하게 통합된 시스템에서 시스템의 준수 여부를 평가하는 테스트이다. 시스템의 기능 측면뿐만 아니라 비 기능적 요구사항을 시스템이 만족하는지 여부를 검증한다

인수 테스팅(Acceptance Test) 가. 정의
개발된 시스템이 고객의 요구사항과 일치하는지 확인하기 위해 고객의 입장에서 수행하는 테스트이다. XP(eXtream Programming) 에서는 애자일 개발 방법론의 XP 구현 단계에서 개발팀이 사용자 스토리 기반의 기능을 테스트하는 것으로 정의하고 있다 나. 목적
시스템을 당장 사용할 수 있도록 모든 준비가 되어있는지 테스트
개발한 사람이 시스템을 사용할 모든 준비가 되었다는 것을 확인시켜 주는 작업 다. 방법
시스템 테스팅과 동일하지만 다른점은 사용자 환경에서 테스트 라. 성능 테스트와 스트레스 테스트도 진행 마. 종류
사용자 인수 테스팅 : 비즈니스 사용자가 시스템 사용의 적절성을 확인
운영상의 인수 테스팅 : 시스템 관리자에 의한 테스트(백업/복원 테스팅, 재난복구 테스팅, 사용자 관리 테스팅, 유지보수 작업, 보안 취약성에 대한 정기적인 점검)
계약 인수 테스팅 : 맞춤식 개발 소프트웨어가 계약상의 인수 통과 조건을 준수하는지 확인하는 테스팅
규정 인수 테스팅 : 정부 지침, 법률 또는 안전 규칙 등 준수해야 하는 규정에 맞게 개발되었는지 확인하는 테스팅
알파 테스팅과 베타 테스팅
불특정 다수의 사용자를 위한 인수 테스트 가. 종류 1) 알파 테스트(공장 인수 테스팅)
선택된 사용자가 개발환경에서 테스트
개발 조직 내에서 고객에 의해 수행
개발자가 소프트웨어를 테스트하는 사용자를 모니터하면서 오류와 문제점을 기록
사용자에 의해 테스트가 수행되지만 개발자 환경에서 통제된 상태로 수행 2) 베타 테스트(사이트 인수 테스팅)
실제 환경에서 사용자 혹은 잠재 고객에 의해 수행
고객의 사용 환경에서 테스트
개발자 없이 사용 환경에서 소프트웨어를 설치하여 테스트
개발자가 참여하지 않는 테스트로 일정 수의 사용자들에 의해 수행
고객 : 모든 문제를 기록하여 개발자에게 보고
개발자 : 소프트웨어를 변경하고 다시 테스트하여 고객에게 인수 나. 장점
소프트웨어를 실제 사용자 환경에서 사용할 사람에게 의하여 테스트함으로써 매우 현실적임
개발하는 과정에서 판에 박은 테스트 방법으로 발견하지 못한 오류를 사용자가 발견 다. 단점
소프트웨어에 많은 오류가 포함되어 있다면 고객이 구매를 보류

테스트 자동화 가. 테스트 자동화의 정의
SW 테스트의 계획, 실행, 보고등의 전반적인 테스트 활동을 자동화시켜 SW 의 품질향상을 높이기 위한 방안 나. 테스트 자동화의 특징

특징 설명 추적성 부여 테스트 케이스 설계부터 테스트 실행까지 전반적인 테스트 활동을 지원, ALM과 연계 재사용성 강화 레파지토리 운영을 통한 테스트 케이스/테스트 오라클의 재사용 및 체계적인 버그정보 관리 품질 향상 반복테스트, 다양한 SW Metric의 반영을 통한 SW의 품질 향상 기대

다. 테스트 자동화 선택 기준

선택기준 설명 투입 노력 ROI, 노력, 비용을 고려하여 자동화 선택(UI 테스트는 자동화를 통한 재사용성에 한계) 테스트 생명주기 재사용 예상 횟수 고려(1~2회 사용할 테스트를 과연 자동화 시킬 것인가?) 가치(value) 리그레션 테스트와 같이 테스트 자동화를 통해 얻을수 있는 가치 판단 정확성 테스트 자체의 버그로 인해 실패할 테스트의 확률(False Positive)

테스트 자동화의 구성요소 및 수행 단계 가. 테스트 자동화의 구성요소

구성요소 설명 Plan 테스트 케이스 정의 및 분류 Authoring 테스트 케이스를 수행하기 위한 문서 혹은 자동화 도구 스크립트를 생성 Execution 테스트를 실행하고 테스트 결과를 산출 Reporting 테스트 실행 결과 및 진행상황등을 체계적으로 분석/보고, 레파지토리 사용

나. 테스트 자동화의 수행 단계(search)

수행 단계 설명 Setup 실제 테스트를 위한 동작이 수행가능한 상태로 SW 준비 Execute 테스트 자동화의 핵심, 기능과 충분한 오류 핸들링 테스팅 수행 Analyze 테스트가 통과했는지 실패했는지의 결과를 확인하는 프로세tm Reporting 로그파일, 데이터베이스, 리포트파일로의 생성 및 분석 Clean Up 다음 테스트가 진행될 수 있도록 초기화 수행(메모리 초기화 등) Help 테스트 케이스 유지 관리를 위한 도구(테스트 케이스 번호, 설명, 사용사례 등)

다. 테스트 자동화 개념도

1 테스트 케이스 분석 테스트 하네스가 동작을 시작하고 넘어온 데이터를 검사 2 테스트 실행 (테스트 수행 엔진) 테스트 하네스가 테스트 케이스를 실행 예) harness.exe TestCase.dll –testcase 1-100 –repeat 10 –output test.log : Testcase 1~100까지 10번 반복하고 결과를 test.log 에 기록 3 테스트 분석 테스트 오라클을 이용하여 테스트 오라클 레파지토리와 실행결과를 비교 4 버그 분석/추적 실패된 테스트에 대해 버그리포트 추적 및 데이터베이스화

테스트 자동화의 동향
회귀테스트등의 반복 테스트시 유용하게 사용되며, 다양한 CASE 도구에서 지원함
IBM Rational ClearQuest 및 MS Team Foundation Server 와 같이 ALM 을 지원하는 도구와 함께 사용중 나. 테스트 자동화 수행시 고려사항

고려사항 설명 테스트 오라클 - 테스트 예측결과를 계산하기 위해서는 해당 도메인에 대한 전문적인 지식습득 필요 - 요구사항 명세서와의 일치를 위한 요구사항 추적 매트릭스를 통한 검증이 요구됨 ALM 연계 - APP 개발/운영의 체계적인 생명주기 관리를 위한 ALM과의 연동 및 추적인 요구됨

테스트 자동화 도구 가. 정의
테스트 관리, 소스코드 리뷰 및 인스펙션, 테스트설계 및 개발, 테스트 수행 등의 테스팅 과정을 하드웨어적 혹은 소프트웨어적으로 자동화할 수 있도록 지원하는 도구
테스팅과정의 생산성 및 신뢰성 향상과 품질 향상에 기여 나. 테스트 자동화 도구 종류
코드 분석 도구
테스트 케이스 자동 생성 도구
테스트 실행 도구
테스트 자동화 코드 분석 도구 가. 정적 분석(static analysis) 도구 : 프로그램을 실행하지 않고 분석하는 도구 1) 코드 분석 도구
소스코드의 문법적 적합성을 자동으로 평가하여 잘못된 문장을 표기, 문법이 틀렸다거나 아니면 오류가 포함될 가능성이 많다거나 아이템이 정의되지 않았을때 위치를 표시
변수가 어디서 정의되었고 언제 사용되었는지 심볼 테이블에 기록하고 각 변수가 사용되기 전에 정의되었는지 또 정의되고 사용하지 않은 변수는 없는지 검사하는 define-use 테스트 2) 구조 검사 도구
입력으로 제공된 소스코드의 그래프를 생성하여 논리 흐름을 보여주고 구조적인 결함이 있는지 체크(ex : 실행 경로가 없는 데드 코드를 발견하여 알려줌)
프로그램을 읽어 모든 반복 구문의 위치를 찾아내고 실행될 수 없는 문장을 표시하며 반복 구문 안에서 분기되는 부분에 주의 표시 3) 데이터 분석 도구 :
소스코드에 정의된 데이터 구조, 데이터 선언, 컴포넌트 인터페이스를 검사하여 잘못된 링크나 데이터 정의 충돌, 잘못된 데이터의 사용 등을 발견
피젯수가 0으로 값이 배정되거나 함수 사이의 매개변수가 부적절하게 전달되는지 체크 4) 순서 검사 도구
이벤트의 순서를 체크, 잘못된 순서로 코딩되어 있다면 이벤트를 지적
시스템의 입출력 컴포넌트를 받아들여 사용하기 전에 모든 파일이 열려 있는지 검사(이벤트 순서가 올바른지 검사) 나. 테스트 자동화 동적 분석(dynamic analysis) 도구 : 프로그램이 실행되면서 분석하는 도구 1) 프로그램이 수행되는 동안 이벤트의 상태를 파악하기 위하여 특정한 변수난 조건의 스냅샷(snapshot)을 생성 2) 수행되는 프로그램의 동작이나 반응을 추적하고 보고하기 위한 것이므로 프로그램 모니터라고도 함 3) 모듈이 호출되는 횟수나 수행된 문장 번호 리스트를 생성
프로그램이 수행도중에 어디서 분기되었는지 정보
테스트 검증 기준이 얼마나 만족되었는지 알려주는 정보 4) 시스템의 성능을 평가하는데 도움을 줌
특정한 변수의 최소값, 최대값, 중간값 같은 정보가 시스템의 성능 또는 기능에 영향을 주는 분기점(breakpoint)을 파악
분기점을 정하여 그 값에 도달하면 그 때의 시스템의 상태, 변수의 값이나 메모리의 상태등을 알려줌 5) 고려사항
실시간 시스템의 경우 프로그램이 수행되는 동안 정보를 얻기가 쉽지 않음
테스트 조건이나 캡처링 명령을 지시하기 어려움
테스트 자동화 테스트 케이스 자동 생성 도구 가. 자료 흐름도
원시 프로그램을 입력받아 파싱한 후 자료 흐름도를 작성하여 define-use 관계를 찾아냄
찾으려는 변수에 영향을 주는 요소들을 모아 테스트 경로를 구동시키는 입력값을 찾아냄 나. 기능 테스트 방법
주어진 기능을 구동시키는 모든 가능한 상태를 파악하여 이에 대한 입력을 작성 다. 입력 도메인 분석
소스코드의 내부를 참조하지 않고 입력 변수가 가질 수 있는 값의 도메인을 분석하여 테스트 데이터를 만드는 방법 라. 랜덤 테스트
입력값을 무작위로 추출하여 테스트하는 도구
시스템의 신뢰성 분석에 사용
테스트 자동화 테스트 실행 도구 가. 캡처 및 리플레이
테스트 계획에 표시된 테스트 데이터를 자동으로 입력하고 실행 과정에 발생하는 화면이나 인쇄되는 결과를 캡처하여 예상되는 결과와 비교하는 도구
예상되는 결과와 차이를 보일 경우 테스트 프로그래머에게 보고
오류를 발견하고 수정한 후 고치는 작업이 바르게 되었는지 확인하는데 유용 나. 스터브와 드라이버
자동적으로 스터브와 드라이버를 생성하는 도구 다. 자동 테스트 환경
테스트 수행 도구들이 테스트 환경으로 통합되어 제공되는 형태
테스트 데이터베이스, 측정 도구, 코드 분석 도구, 텍스트 편집기, 시뮬레이터, 모델링 도구 등이 테스트 작업을 자동화하도록 제공

테스트 용이성(Testability)
소프트웨어 제품의 가시성(Observability)과 제어성(Controllability)을 의미
비기능적인(non-functional) 요구사항
기능이나 코드의 테스트가 손쉬운지를 판단하는 특성
테스트를 시스템적으로 수행할 수 있도록 하기 위해 소프트웨어에 미리 준비된 어떤 것
테스트 용이성의 중요성
소프트웨어 테스팅의 목표는 주어진 조건하(제약된 시간)에서 많은 결함을 찾는 것이므로 테스트 효과성(Test Effectiveness)과 테스트 효율성(Test Efficiency)에 지대한 영향을 미침
제품 상태에 대한 파악이 용이하고 제어된 환경에서 제품을 구동, 간단한 방법으로 제품의 모드를 변경하는 등의 일련의 활동을 통해서 제품을 좀더 다양한 입력조건/동작조건하에서 놓이게 하면 할수록 문제를 발견해 낼 확률이 더욱 높아지기 때문이다. 특히 제품 출시 이후에 반드시 수행될 수밖에 없는 회귀 테스트, 확인 테스트 등에서 동일한 테스트를 여러번 반복해야 하는 상황인 경우, 더욱 극명하게 드러내는데 테스트 용이성이 향상되고 높을수록 적은 리소스로 테스트 수행할 수 있음은 물론이고 테스트 자동화 구현이 용이하기 때문이다.
테스트 용이성의 단계별 향상 방안 가. 요구사항 정의 단계
명세를 기반으로 하는 테스트 케이스 설계
개발팀의 협조를 구함 나. 디자인 단계
테스터의 지식수준이나 제품의 성격, 프로젝트 상황에 따라 사용할 수 있는 테스팅 인터페이스, 제품 내의 테스트 코드 또는 부가적인 테스팅 툴에 대한 요구 스펙을 정해 개발팀에 전달해야 한다. 다. 코딩 단계
제품의 일부 기능을 동작시킬 수 있는 스텁과 드라이버 등을 제작하고 구현
코딩 표준을 준수
테스트 자동화(CI환경, 테스트 인프라 구축), JUIT 등 활용, 자동화
TDD 구현 라. 테스트 단계
테스터 역시 디버깅 환경에 익숙해지고 그런 환경에서 테스팅을 진행하게 되면 개발팀의 시간을 많이 절약하게 되고 테스터 역시 버그를 찾아낼 가능성이 높다

I. SW 신뢰성 확보를 위한 회귀 테스트의 개요 가. 회귀 테스트의 정의 - 오류를 제거하거나 수정한 시스템이나 시스템 컴포넌트 또는 프로그램이 오류 제거와 수정에 의해 새로이 유입된 오류가 없는지를 확인하는 반복 시험회귀 테스트의 수행 목적 나. 회귀 테스트의 필요성 - 운영상의 일부 모듈의 변경에 따른 전체적인 정합성 테스트 - 기존의 수정된 버그가 변경에 의하여 다시 발생할 가능성 방지 - 기존 버그 수정을 위한 변경으로 인하여 예상하지 못한 버그 발생 방지 다. 회귀 테스트의 특징 - 테스트의 중복을 피하기 위하여 테스트 재사용하는 유지보수 단계의 테스트 방법이나 모든 테스트 레벨에서 수행 가능 - 오류를 발견하고 고치고 다시 원래 문제를 일으켰던 것을 반복 테스트를 통해서 확인 - 수정된부분이 다른 부분에 영향을주어 예상하지 않은 오류를 발생시키지 않는 지 확인 - 수정 후 프로그램의 통합이 제대로 이루어졌는지 확인 II. 회귀 테스트의 비교 및 절차 가. 결함 테스트와의 특징 비교

구분 결함 테스트 회귀 테스트 개념 테스트 케이스들의 실행을 통해 발견하지 못한 오류를 찾아내는 테스트 테스트된 프로그램을 변경 후에 변경 결과로 수정되지 않았거나 발견되지 않는 결점을 발견하기 위해서 반복 특징 - 모든 가능한 입력과 사용자의 행위를 위한 테스트 케이스를 생성하는 것은 불가능 - 문제를 최대한 찾아낼 수 있도록 테스트를 디자인 - 오류를 수정하는 행위가 새로운 오류를 발생시킬 수 있으며, 오류들의 수정 후에 결함 발견 - 스텁과 드라이버는 재사용 가능 - 테스트 케이스도 수정하여 사용 가능

나. 회귀 테스트의 수행 시기 - 기능 변경 시 : 개별 단위 테스트를 수행한 후, 테스트 Repository에 관리되어 있는 이전 기능 테스트 케이스를 통한 안정성 검증 실시 - 환경 수정 시 : 다국어지원, 지원 환경(OS, 플랫폼 등)의 변경 시 통일 기능 수행 여부에 대한 점검 실시(예 : Windows Vista 환경 아래에서의 정합성검증)

다. 회귀 테스트 절차 1) 테스트 수행 전 확인 사항 - 프로그램 변경 후 단위 기능 테스트 수행 완료되어야 함 - 변경된 각 모듈의 통합 – 배포 수정까지 빌드 실시 2) 테스트 케이스 라이브러리에 의한 회귀 테스트 실행 - 단위 기능중심의 이전 기능 테스트 실시 - 통합 기능의 시나리오 기반의 테스트 실시 - 반복 및 제약 부하 환경에서의 성능 테스트 실시 3) 결과 기록 및 사후 검증 - 테스트 수행 결과를 기록하고 성공여부 점검(체크리스트 기반) - 테스트 성공 이후, 기존 단위 테스트의 회귀 테스트 Repository에 저장 - 변경된 기능 및 시나리오를 감안한 테스트 절차 최신화 실시(다음 회차 회귀 테스트에 적용) III. 회귀 테스트 적용 시 고려사항 및 효율적인 회귀 테스트 방안 가. 회귀 테스트 적용 시 고려사항 1) 과다 테스트 : 변경 영역에 근접한 모듈과 이전에 오류가 발생한 영역의 오류발생 빈도 높음을 감안, 경험적인 범위 적용 2) 과소 테스트 : 사용자 중심의 반복적이고 고객 확인이 가능한 영역에 대한 테스트 집중 (매뉴얼 및 시나리오 기반의 테스트 수행 절차 확립) 나. 효율적인 회귀 테스트 방안 1) 프로세스 관점(절차적 예측성 향상) - Quality Assurance팀 운영 : 테스트 전문 담당팀 구성, 개발 이후 안정적인 배포까지의 프로세스 일임 - 선진 프로세스 적용 : 반복적인 요구 적용에 대한 ITIL 등의 사례 참조/적용 2) 시스템 관점(업무 가중 부하 최소화) - 테스트 자동화 : 검증 작업 및 오류 리포트, 빠른 회귀 테스트를 위해서 테스트 자동화시스템 고려 - 다양한 테스트 케이스와 시나리오 및 환경 기반으로 안정적인 소프트웨어 납품 기대 다. 회귀 테스트의 실제 활용 - 익스트림 프로그래밍 등 반복적, 지속적 변경시 효율적 테스트 방안으로 필수 활용 - 응집도를 높이고 결합도를 낮게 설계하여 변경에 대한 영향을 최소화 필요 - 대규모 프로젝트에서는 모든 변경에 대한 종합 테스트 성격으로 주기적으로 실시 필요

구조기반 테스팅에서 소스코드 커버리지 개요 가. 소스코드 커버리지의 정의
소프트웨어 테스트 수행시 소스코드를 어느 수준까지 테스트 수행 하였는지를 나타내는 화이트박스 테스트 나. 소스코드 커버리지의 유형

구분 설명 Function 커버리지 소프트웨어 내에 정의된 Function이 호출되는 정도 statement(구문) 커버리지 소프트웨어 내에 기술된 Statement가 수행되는 정도 Decision(결정) 커버리지 소프트웨어 내에 기술된 조건문이 참/거짓 모두 수행되는 정도 Condition(조건) 커버리지 소프트웨어 내에 기술된 조건문에서 사용되는 개별 조건이 참/거짓 모두 수행되는 정도 Modified Condition (수정 조건)커버리지 소프트웨어 내에 기술된 조건문에 참/거짓이 되기 위한 조건들의 가능한 조합 모두가 수행되는 정도 Path(경로) 커버리지 모든 경로를 적어도 한번은 수행을 하도록 테스트 케이스를 작성

구문/결정/조건 커버리지의 관계도 및 사례 가. 구문/결정/조건 커버리지의 관계도
구문(Statement) 커버리지는 결정/조건 커버리지가 만족되면 자연스럽게 만족
결정(Decision)과 조건(Condition) 커버리지는 공통되는 부분도 있지만 그렇지 못한 부분도 존재 나. 구문/결정/조건 사례 If a > 0 and a > b then begin C = b + C print C; end Else begin d = b + C print d; end
위의 소스코드 중에 분 구문에 해당하는 a > 0 and a > b의 결정조건에 따라서 아래의 표와 같은 테스트 케이스 산출

번호 a값 b값 a>0의 결과 a>b의 결과 a>0 and a>b의 결과 1 1 0 T T T 2 1 1 T F F 3 0 1 F F F 4 0 -1 F T F

1, 2번을 선택하면 전체 결과 T, F이기 때문에 Decision 커버리지 만족
1, 2번을 선택하면 a>0의 결과가 항상 T이기 때문에 Condition 커버리지 만족하지 않음
2, 4번을 선택하면 a>0과 a>b의 결과가 각각이 모두 T, F를 만족하기 때문에 Condition 커버리지를 만족
2, 4번을 선택하면 전체결과가 모두 F이기 때문에 Decision 커버리지 만족하지 않음
구문/결정/조건 커버리지의 구조기반 테스트 활용방안 가. 구조기반의 테스트 수행 시 가장 달성하기 쉬운 구문(Statement) 커버리지를 달성하기 위한 테스트 케이스 먼저 작성 나. 구문 커버리지가 달성되면 결정(Decision) 커버리지를 달성하기 위한 테스트 케이스 고려 다. 결정 커버리지가 달성되면 조건(Condition) 커버리지를 달성하기 위한 테스트 케이스 고려

1) 구문커버리지 (Statement) : 프로그램 내의 모든 명령문을 적어도 한번 수행하는 테스트 케이스 2) 결정 커버리지 (Decision) : 프로그램 내의 전체 결정문이 적어도 한번은 참과 거짓의 결과를 수행하는 테스트 케이스 3) 조건 커버리지 (Condition) : 결정 명령문 내의 각 조건이 적어도 한번은 참과 거짓의 결과가 되도록 수행하는 테스트 케이스 4) 조건/결정 커버리지 (Condition/Decision) : 전체 조건식 뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되도록 수행하는 테스트 케이스 5) 변경조건/결정 커버리지 (Modified Condition/Decision) : 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 독립적으로 영향을 주도록 하는 테스트 케이스 6) 다중조건 커버리지 (Multiple Condition) : 결정 포인트내에 있는 모든 개별식 조건의 모든 조합을 고려한 커버리지

소프트웨어 품질확보를 위한 활동 테스트의 개요 가. 테스트의 정의
수작업 또는 자동화된 방법으로 프로그램의 규정된 요구사항을 만족 시키고 있는지 검증하고, 예상한 결과와 실제결과의 차이를 식별하기 위해 시스템이나 시스템 구성요소를 실행하고 평가하는 과정 나. 테스트의 목적[Gien Myers] 1) 결점을 찾기 위한 목적으로 프로그램을 실행하는 과정 2) 좋은 테스트 케이스는 아직 발견되지 않은 오류를 찾아내는데 높은 가능성을 가지고 있음 3) 성공적인 테스트는 아직 발견되지 않은 오류를 찾아내는 것 다. 테스트의 주요 기법

코드기반(Code-Based) 테스트 결함기반(Fault-Based) 테스트 시스템 또는 소프트웨어의 코드와 구조를 중심으로 테스팅하는 기법 리스크가 높은 영역은 동원할 수 있는 모든 리소스를 투입하여 완성도 높게 테스트하고 리스크가 낮은 영역은 그에 맞는 리소스 사용하려는 테스트

코드기반(Code-based) 테스트 방법

테스트 방법 설명 구문 테스팅과 커버리지 (Statement testing and Coverage) 테스트 케이스 스위트에 의해 실행된 구문이 몇 퍼센트인지를 측정하는 것 코드의 모든 구문을 실행 할 수 있는 입력 값이나 이벤트 등의 테스트 데이터를 제공 해주면 달성 적은 개수의 테스트 데이터로 쉽게 달성 할 수 있지만 보장성 낮은 커버리지 결정 테스팅과 커버리지 (Decision testing and Coverage) 테스트 케이스 스위트에 의해 실행된 결정문의 분기(if구문의 참 분기 혹은 거짓 분기)가 몇 퍼센트인지를 측정하고 평가 결정 포인트 내의 전체 조건식이 “참”과 “거짓”의 모든 값을 갖게 되어 모든 분기로 제어가 흐르게 되면 달성 구문 커버리지보다 강력, 100% 포함 조건 테스팅과 커버리지 (Condition testing and Coverage) 결정 포인트 내에 있는 개개의 개별 조건식이 “참”과 “거짓”의 모든 결정 인 내에 있는 개개의 개별 건식이 참과 거짓의 든 값을 갖게 되면 달성 개별 조건식이 모두 “참”, “거짓”을 가진다고 해서 전체 조건식이 항상 “참”, “거짓”을 갖지는 않음

변경 조건/결정 커버리지 (MC/DC) 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 함. 결정 커버리지, 조건/결정 커버리지 보다 강력 3. 결함 기반(Fault-based)테스트 방법

테스트 방법 설명 오류 추측 (Error guessing) 오류추측 기법에서의 테스트 케이스는 SW 기술자에 의해 특별히 설계되어 프로그램 내에 가장 그럴듯한 오류를 이해하기 위해 사용됨 변이시험 (Mutation testing) 의도적으로 컴포넌트나 시스템의 소스코드(source code)를 변형시키고 이에 맞게 디자인된 테스트 데이터를 실행시켜 프로그램 코드 내에 존재할 수 있는 애매모호한 부분을 찾아내는 테스트 기법 변이(mutant)는 시험 내에서의(구문 변화를 통한) 아주 작은 수정 버전으로, 모든 테스트 케이스는 원 버전과 모든 변이버전 모두에 수행됨 만약 테스트 케이스가 프로그램과 변이와의 차이를 성공적으로 식별하면 해당 변이는 '죽었음(killed)'이라 함

소프트웨어 테스트 품질 확보방안 가. 테스트 자동화 툴 활용 : 테스트 생산성 확보 및 Human Error 최소화, SW품질확보 나. TMM 도입
소프트웨어 시험조직의 성숙도를 평가하는 모델
SW-TMM는 테스팅 성숙도 수준의 베이스 라인을 설정하고, 조직에서 생각하고 있는 성숙도 수준과 실제 성숙도 수준과 불일치하는 것을 조명하며 또한, 테스팅 프로세스개선을 위한 방향(roadmap)을 제공 ※ TMM(Testing Maturity Model) : 소프트웨어 테스팅 프로세스 성숙도 수준 측정 모델 다. 테스트 문서의 표준화 : 테스트 기법 및 문서를 표준화 시켜 재사용성 향상시킴 라. 테스트 전문가 양성 : 특정 시스템 및 범용 시스템의 테스트를 효과적으로 수행 할 수 있는 전문가 양성

I. 우선순위에 기반한 고품질의 테스트 전략 리스크 기반 테스트의 개요 가. 프로젝트 복잡성에 따른 위험요인 증대

최근 프로젝트는 점점 대형화, 복잡화에 따른 다양한 위험의 증가 추세에 있으며, 이를 해결하기 위해 프로젝트 초기부터 정량적 위험 요소를 측정, 우선순위화를 통해 프로젝트 위험 최소화 전략이 필요함 나. 리스크 기반 테스트의 개념 및 목적
비즈니스, 기술상의 위험을 정량적으로 측정하여 우순 순위가 높은 부분에 주어진 테스팅 자원을 집중, 전체적인 영향을 줄이기 위한 테스트 전략
즉, 테스트 해야 할 부분과 테스트 단계별 우선순위를 식별하여 테스팅 측면에서 프로젝트의 리스크를 최소화 하는 기법
효과성 : 계획된 테스트의 결과 산출, 발견용이 및 높은 영향도의 결함 발견 가능
효율성 : 예상 테스트 결과의 생산적 수행, 가용 자원의 최적 배치 II. 리스크 기반 테스팅의 수행 절차 및 테스팅 조건 가. 리스크 기반 테스팅의 수행 절차

단계 Activity 산출물 Risk 식별 발생 가능 위험의 카테고리화 Risk Item Risk 분석 식별 위험의 정량적 분석(발생가능성, 영향도) 위험/영향 Metric Risk 대응계획 위험 항목별 완화, 최소화 대응 계획수립 위험 대응 목록 테스팅 전략 수립 대응 계획에 충족하는 테스트 종료 결정, 완료 조건, 목표 수준 등 정의 Master Test Plan Risk 추적 리스크 및 리스크에 대한 대응을 모니터링 위험 관리 대장

나. 리스크 기반 테스팅의 성공적 수행의 위한 조건 - Risk 정량화 : 발생 가능성, 영향도에 따른 차별화된 Metric 결정 - 우선순위 결정 : 우선순위 높은 테스트 집중, 파레토 법칙의 적용, 제한된 자원의 효율적 배분 - 테스트 계획 : 식별된 리스크의 정량화, 우선순위 기반하에 일정, 비용, 인력, 프로세스의 조정 III. 리스크 기반 테스팅 단계별 전략 및 사례 가. 리스크식별

발생가능성 : 팀 내부 구성원의 갈등, 공급자와 계약상의 문제, 잘못된 관리/기술적 리더십, 요구사항/설계/코드의 잦은 변경, 기술의 최신성 등
영향(Impact) : 고객 및 사업상의 손실, 민/형사상의 제재, 라이센스 및 허가 손실, 제품 실패 가능성 등 나. 리스크 분석
발생가능성, 영향도 별 정량적 기준에의한 점수화 다. 리스크 기반 테스팅 계획/추적
리스크 별 위험 최소화 대응 계획
리스크 레벨에 따른 완료조건, 테스트 인력, 리포팅 방법 결정 IV. 리스크 기반 테스팅의 활용 시 고려사항
프로젝트 위험관리와 연계, 테스트 수행에 필요한 식별된 Risk의 적극적 활용 및 테스트 일정에 따른 테스트 계획의 변경
리스크가 높은 부분에 있어서는 경험많은 인력의 배치
지속적 위험 현행화, 프로세스 기반 업무 정의 및 모니터링

임베디드 시스템의 개요 가. 임베디드 시스템(Embedded System)의 정의
군사, 산업기기, 통신기기, 가전기기, 자동차 전용 기기 등 다양한 응용에 사용될 수 있는 다른 시스템에 포함되는 부분적인 시스템
기능 및 구성의 복잡도를 줄이고 중복 활용이 가능하여 개발 기간 단축이 용이하고 유연한 구조를 갖춘 하드웨어 및 소프트웨어가 결합된 플랫폼 나. 임베디드 시스템의 구성요소
임베디드 개발도구 : Host 시스템과 Target 시스템 동시지원, 하드웨어 최적화된 개발지원
임베디드 미들웨어 및 보안시스템 : 방송용 미들웨어를 탑재한 STB, Anti Virus 시스템
임베디드 기본/공통 응용 소프트웨어 : 멀티모달 인터페이스, 임베디드 브라우저/스트리밍
임베디드 운영체제 : RTOS, TinOS, Nano Qplus, MontaVista, Thread기반과 Process 기반으로 나누어짐
임베디스 시스템을 테스트하기 위한 하드웨어 테스트 기법

테스트 기법 구성도 설명 풀 ICE (In Circuit Emulator)

CPU 자체를 치환하고 CPU의 동작을 흉내내어 프로그램의 동작을 테스트할 수 있는 기법 ROM 모니형

모니터란 값이나 상태를 표시하는 기능을 가진 테스트 기법 ROM에 기입된 프로그램을 ROM 모니터라 하는데 여기에 디버그 기능을 내장하여 디버거로써 사용하는 테스트 기법 Rom Emulator

ROM 상에서 동작시키는 프로그램을 다운로드하여 테스트하는 기법 JTAG

SoC가 사용되면서 CPU 및 ROM을 떼어낼 수 없는 환경이됨 Debug 전용의 JTAG 단자를 이용하여 Host와 통신하는 테스트 기법

소프트웨어의 하드웨어 테스트에서의 스모크 테스트 가. 스모크 테스트(smoke test)의 정의
본격적인 테스트의 수행에 앞서, 시스템, 컴포넌트, 소프트웨어 프로그램 등 테스트 대상이나 제품의 빌드(제품 설치 패키지)가 구축된 테스트 환경에서 테스트가 가능한지 여부를 판단하기 위해 주요 모듈이나 시스템을 간단하게 테스트 하는 것.
예 : 장치가 제대로 원활히 동작하는지의 여부를 알아보기 위해서 처음에 전원을 넣는 것 나. 스모크 테스트의 특징
스모크 테스트는 개발팀이 제작한 주요 단위 모듈이나 시스템 모듈을 제3자 테스트팀 또는 개발팀 내의 테스트팀이 주체가 되어 테스트 케이스 없이 시행
테스트 환경을 처음 구축할 때 끝단(end-to-end)까지 점검하여 테스트 환경 자체에 문제가 없는지 확인한 다음 이상이 없을 때 실시
만일 테스트 대상이나 제품의 빌드가 테스트를 수행하기에 완성도가 낮다면 개발 조직이 제품 완성도를 높이는 작업을 하도록 테스트 분석 정보를 제공
임베디드 시스템을 테스트하기 위한 소프트웨어 테스트 기법 가. 이벤트 기반의 시스템 테스팅을 위한 Record and Replay 기법의 개념
사용자의 입력과 외부 메시지로 구성되는 이벤트에 대해서 임베디드 소프트웨어가 정확히 대응하는 지를 테스팅하는 기법
타겟 시스템에서 발생하는 사용자 입력 및 외부 이벤트를 녹화해서 테스트 스크립트로 구성하고, 이 스크립트를 재수행해서 결과를 확인하는 방법 나. 이벤트 기반 시스템 테스팅의 출현배경 1) 비순차적인 실행으로 인한 선후관계 파악의 어려움 2) 비동기적인 동작으로 인한 문제발생 포인트의 확인 불가 3) 다수의 이벤트 발생지로 인한 예측의 어려움 4) 테스트 플랫폼의 다양성에 맞춰 계획, 이행, 결과분석의 어려움 5) 테스트 플랫폼 및 환경설정의 오류 다. 구성도

라. 구성요소

구분 단계 설명 사용자 이벤트 녹화(Record) ① 기능테스팅 캡처 시작 테스팅 관리자 웹브라우저를 통해 기능 테스팅 캡처 시작을 명령 ②,②’이벤트후킹 (Event Hooking) 타켓 시스템에 설치된 테스트 에이전트가 테스팅 대상 응용프로그램에서 발생되는 이벤트를 가로챔 ③ 이벤트 송신 타켓 시스템의 테스트 에이전트는 단말의 통신 인터페이스를 이용하여 테스트 시스템으로 이벤트를 전송 ④ 이벤트 저장 테스트 시스템의 캡처 모듈은 타켓 시스템의 테스트 에이전트가 송신한 이벤트 메시지를 XML형태로 변경하여 저장함. 사용자 이벤트 재생(Replay) ⑤ 기능 테스팅 재수행 시작 테스팅 관리자 웹브라우저를 통해 기능 테스팅 재수행 시작을 명령 ⑥ 이벤트 검색/변환 테스트 시스템의 재수행 모듈은 XML로 저장된 이벤트를 RAW 이벤트로 전환 ⑦ 이벤트 통신 전송 타켓 시스템의 테스트 에이전트에게 RAW이벤트 메시지를 발송 ⑧ 이벤트 전달 타켓 시스템의 테스트 에이전트는 수신한 RAW이벤트 메시지를 대상 프로그램에 전달 ⑨, ⑨’ 결과전달 타켓 시스템의 테스트 에이전트는 테스팅 결과를 테스트 서버의 결과 처리 모듈에 전달

마. 적용사례 1) 임베디드 시스템의 이행 테스트시 적용 2) BRE에서 사용되는 CEP(Complex Event Processor)의 테스팅
바. 주요이슈

특징 설명 Event Driven User-driven기능과 event-driven기능이 혼재됨 Time critical 때때로 시간 제약사항이 있는 경우가 존재함 Platform Diversity 플랫폼(H/W, OS 등)이 다양함 Platform stability 플랫폼(H/W, OS 등) 자체에 오류가 있는 경우가 있음 Development Environment 컴파일러, 라이브러리 등이 불완전한 경우가 있음

사. 이벤트기반 시스템 테스팅 시 고려사항 1) 테스트 에이전트 개발시 물리적인 제약사항을 고려해 개발되야 함 2) 테스팅과정에서 많은 양의 산출물을 발생하는데, 산출물 관리에 유의 3) 호스트와의 통신 환경이 시리얼 라인밖에 없으므로 효율적인 데이터 관리가 매우 중요함 아. 이벤트 기반 시스템 테스팅 해결과제 1) 임베디드 시스템에서 자주 발생하는 실시간성과 인터럽트 처리에 대한 테스팅 방법 부족 2) 비동기적인 인터럽트가 시스템 기능 및 성능에 끼치는 영향을 테스팅하는 기법 필요

경험기반 테스트의 개념 가. 경험기반 테스트의 정의
유사한 분야의 S/W나 테스터의 과거 경험을 바탕으로 직감적으로 테스트하는 기법
Formal 기법과 같이 사용하며, Formal 기법이 찾기 어려운 결함 발견 기능 나. 경험기반 테스트의 특징
테스트의 경험에 따라 효과가 다르기 때문에 일관성이 떨어지며 관리가 어렵다.
경험기반 테스트의 기법 가. 기법 유형별 특징

구분 설명 비고 탐색적 테스팅 (Exploratory Testing) - 테스트 목표와 차터(charter)를 기반으로 정해진 시간내에 설계, 수행, 기록과 학습하는 테스팅 기법 - 명세가 거의 없고 시간이 부족한 경우 적합 Formal 기법 보충 오류추정 (Error guessing) - 가능한 결함을 리스트업하고 이를 발견하기 위한 케이스 작성 - 가능함 결함(에러, 오류)은 상식, 기존 경험과 기존 데이터를 통해 도출 가능 - 기능(블랙박스) 체크리스트 : 최상위 기능 - 시스템 요소 체크리스트 : 개별구문 체크리스트 기반 테스팅 문서기반의 테스트 케이스를 작성시에도 체크리스트의 경험과 노하우를 반영하는 노력 요구 일반적인 경험과 노하우의 경험 분류 트리기법 (Classification Tree Method) - 소프트웨어 일부 또는 전체를 트리(Tree) 구조로 분석 및 표현하고 거기에서 테스트 케이스를 도출하는 기법 - 트리 구조로 시각화하여 테스트 케이스를 설계(트리 구조 끝단의 조합을 통해 테스트 케이스를 작성) 복잡도가 높은 S/W에 적합함

나. 대표적 기법인 탐색적 테스팅의 수행 원리

구분 설명 비고 제품 탐색 (Product Exploration) - 제품의 목적 식별(Identify the purpose of the product) - 제품의 기능 식별(Identify functions) 분석가 테스트 설계 (Test Design) - 잠재적으로 불안정한 부분 식별(Identiy areas of potential instabillity) - 테스트 케이스 도출(실행조건, 입력값, 예상결과) 설계자 테스트 실행 (Test Execution) - 각각의 기능 테스트 및 문제점 기록(Test each function and record problems) - 일관성 검증 테스트 설계 및 기록(Design and record a consistency verification test) 테스터

경험기반 테스트 실행 가이드
탐색적 테스팅은 즉흥적(Ad hoc) 테스팅, 게릴라(Guerrilla) 테스팅, 직관적(Intuitive) 테스팅과 유사한 개념의 테스팅이나, 정해진 임무(Tasks)와 목표(Objectives), 결과물(Deliverables)이 존재한다는 측면에서 다르다.
테스트 절차와 지침에 따라 테스팅 할 때 최대의 효과를 볼 수 있다. (즉흥성과 원칙/절차성의 균형 유지 필요)

테스트 실행 결과의 판단 기준, 테스트 오라클 가. 테스트 오라클(test oracle)의 개념
테스트를 수행 한 결과가 참인지 거짓인지를 판단하기 위하여 미리 정의된 참 값을 대입하여 비교하는 기법 및 활동
테스트 결과가 명세와 일치하는지 판단하기 위한 준거로 모든 테스트 케이스를 위한 예상된 결과 나. 테스트 오라클의 특징(1)

관점 특징 개발자 관점 정상/비정상의 판단 기준 제공 오라클 유형에 따른 다양한 분량의 테스트 데이터제공이 가능함 테스터 관점 테스트 케이스 설계 기초제공 테스트의 철저성을 결정하는 중요한 기초 자료 소프트웨어 유형에 따라서 다양한 테스트를 수행할 수 있는 데이터 제공 관리자 관점 소프트웨어 품질 판단 기준 제공 테스트 활동의 적정성 판단 기준 제공

다. 테스트 오라클의 특징(2)

특징 설명 제한된 검증 모든 테스트 항목에 대해서 100%만족하는 판단을 적용하기 어려움 수학적 기법 사용 테스트 수행 시 수학적 기법을 이용, 오라클 값을 구함 테스트 자동화 활용 자동화 결과의 정확성 보장, 결과값을 자동으로 비교하는 결정자 역할

테스트 오라클의 유형 가. 참 오라클(True Oracle)
모든 입력 값들에 대해 원하는 결과들을 생성하여 발생된 오류를 놓치지 않고 검출할 수 있는 오라클
보통 테스트 대상이 되는 프로그램과는 다른 독립적인 알고리즘을 사용하여 개발하기 때문에 오라클을 개발하는데 소요되는 비용이 크다는 단점.
참 오라클사례

설명 사례 Sine값은 각각의 x값에 따라서 참값이 항상 계산이 가능함. Sine값은 프로그램과는 다른 알고리즘에 의해서 계산이 됨. 즉, 모든 x값에 대해서 오류를 놓치지 않고 검증 할 수 있는 오라클임.

나. 샘플링 오라클(Sampling Oracle) - 특정 몇몇 입력 값들에 대해서만 원하는 결과를 제공해주는 오라클을 말함. - 예를 들어 sine함수를 테스트 할 때0, 90, 180, 270, 360도에 대해서만 정확한 참값을 제공할 수 있는 오라클을 말함. - 샘플링 오라클사례

설명 사례 Sine함수를 테스트 할 때 0, 90, 180, 270, 360도에 대해서만 올바른 결과를 제공하는 오라클.

다. 휴리스틱 오라클(Heuristic Oracle) - 샘플링 오라클의 단점을 개선하기 위해 특정 몇몇 입력 값들에 대해서는 샘플링 오라클의 경우처럼 올바른 결과를 제공하고, 나머지 입력 값들에 대해서는 휴리스틱으로 처리하는 오라클. - 휴리스틱 오라클 사례

설명 사례 예를 들어 sine함수를 테스트 할 때 0, 90, 180, 270, 360도에 대해서만 올바른 결과를 제공한다. 나머지 경우는 실제 sine값을 계산하는 대신 0도부터 90도(또한 270도부터 360)사이의 sine(x)의 값은 x가 증가함에 따라 증가한다는 사실을 이용하고 유사하게 90도부터 180도(또한 180도부터 270도)사이는 x가 증가함에 따라 sine(x)의 값이 감소한다는 사실을 이용하여 실제sine(x)의 실행결과가 올바른 결과인지를 검사한다.

라. 일관성(consistent) 검사 오라클 - 변경이 있는 경우 전후의 결과값이 같은지 확인하는 것 - 사례 : 모든 상용테스트 자동화 도구에서 사용 라. 테스트 오라클 유형간 비교

구분 참오라클 샘플링오라클 휴리스틱 오라클 테스트 정확도 모든 테스트 케이스에 대한 정확도 검증이 됨 일부에 대해서만 테스트정확도 검증이 가능함 참오라클과 샘플링오라클의 중간 정도의 정확도 검증이 가능함 장점 모든 케이스에 대한 테스트 오라클 적용이 가능 테스트 오라클 작성 용이

샘플링 보다는 상대적으로 테스트 케이스 검증수가 많음 단점 오라클 개발 비용이 많음 샘플링 이외의 테스트는 참/거짓 검증이 안됨 값은 조건 값 범위 내의 테스트 참/거짓 검증은 안됨

소프트웨어 품질 향상을 위한 테스트 오라클 적용 방안
항공기, 임베디드, 발전소 소프트웨어 등의 mission critical 한 업무에 들어가는 소프트웨어는 참오라클을 이용한 전체 테스트가 필요함
일반 업무용, 게임/오락 등의 mission critical 하지 않은 업무에 들어가는 소프트웨어는 샘플링, 휴리스틱 오라클을 활용함
테스트 오라클 적용시 고려사항 및 활용방안 가. 일관성검사 오라클을 사용하는 경우 이전 테스트케이스의 보완을 통하여 살충제 패러독스의 문제점을 예방 할 수 있음 나. GUI(Graphic User Interface) 기반, Console 기반의 SW테스트 수행 시 테스트 오라클을 활용하여 테스트 자동화의 정확성 보장에 사용함 다. 참 오라클 : 항공기, 선박 및 기계 제어 장치 시스템 등의 mission critical 한 임베디드 SW에서 사용함 라. 샘플링 또는 휴리스틱 오라클 : ERP, CRM 등 레거시 시스템에서 사용함

SW테스트의 원리, 살충제 패러독스와 오류부재의 궤변의 개념
살충제 패러독스와 오류부재가 제시하는 테스트의 원리 및 비교 가. 살충제 패러독스와 오류부재의 궤변이 제시하는 테스트의 원리

나. 살충제 패러독스와 오류부재 궤변을 통한 관점 비교

살충제 패러독스와 오류 부재의 궤변의 테스트원리에 따른 테스트 전략

가. 살충제 패러독스 원리에 의하여 테스트 케이스의 지속적인 개선 나. 오류부재의 궤변의 원리에 의하여 사용자가 요구하는 품질을 달성 다. 두 가지의 테스트원리는 SW의 품질향상 및 효율적 테스트를 위한 기본전제임

의도된 결함으로 테스트 데이터의 효과성 검증, Mutation Test 개요 가. 뮤테이션(Mutation Test)의 정의
의도적으로 프로그램 소스를 변경시켜 결함을 생성하고, 테스트 데이터의 집합이 효과적으로 의도된 결함까지 구별해 낼 수 있도록 테스트 데이터의 효과성을 검증하는 테스트기법
의도적으로 프로그램의 원시 부호(source code)를 변형시키고 이에 맞게 디자인된 테스트 데이터를 실행시켜 프로그램코드 내에 존재할 수 있는 애매모호한 부분을 찾아내기위한 테스트 기법 또는 테스트 과정(process)
일반적으로 작은 결함까지도 발견하여 테스트한 결과에 신뢰감을 부여하기위해 실시함 나. Mutation 변환 연산자

유형 설명 예시 속성변경 컴포넌트 속성값이나 사용자 속성 값 변경 Setcolor(Red).Width=15 서비스변경 서비스영역 변경이나 서비스 호출순서 변경 Fun(float), A()-C()-B() 입력값 변경 서비스 입력값 변경이나 순서 변경 Fun(a+1), Fun(b, a) 출력값 변경 출력값 변경이나 삭제 Result ++, Result값 삭제

Mutation Test 개념도 및 Process 가. Mutation Test 개념도
원본 소스코드에 속성, 서비스, 입력 값, 출력 값을 변경시켜 테스트를 수행하며, 결과값에 대한 비교를 통해 테스트 데이터 신뢰성 검증
뮤턴트 후의 테스트 결과값이 이전 테스트 결과와 동일할 경우 해당 테스트 데이터의 신뢰성은 낮으며 오류 변별력이 낮다고 판단할 수 있음 나. Mutation Test Process

절차 설명 컴포넌트 변용 컴포넌트 선택, 변용, 통합단계 중 Mutation Test를 위한 변용작업 수행 오류형태 파악 검출하고자 하는 오류형태를 파악(사용자 변용오류, 컴포넌트 자체결함) 연산자 결정 속성변용, 서비스변용, 입력값변용, 출력값변용에 필요한 연산자 결정 테스트 수행 식별된 결함을 피드백하여 컴포넌트의 재변용 및 재시험 실시

뮤테이션 테스트의 문제점 및 발전방향 가. 테스트를 디자인하고 테스트 케이스를 작성하는 것에 지나친 노력이 필요하므로 현재까지도 학계에서 논의만 하고 있는 실정이며 실무에서 폭넓게 사용은 못하고 있음. 나. 자동화된 테스트 툴과 변종을 자동적으로 삽입할 수 있는 툴을 사용함으로써 비효율성을 완화시켜야 함 [참조예제]
t1과 t2는 M1(t), M2(t)에서 결과가 같게 나와 좋은 테스트 데이터라고 할 수 없다. 따라서 좀 더 효과적으로 구별해 낼 수 있는 테스트 데이터를 추가해야 한다. t3의 경우는 foo(t)=0, M1(t)=2, M2(t)=1로 모두 다른 결과를 나타내어 좋은 데이터라 할 수 있다.
비버깅과 뮤테이션의 차이

비버깅 뮤테이션 - 의도적인 오류코드 삽입하고테스트를 통해 잔존오류를 도출하는 작업 - 의도적 오류코드 삽입 생성방식 - 잔존 오류 추정이 목적 - 의도적인 변경(Mutant)을 가하여 테스트 케이스의 적합성 판단 - 뮤턴트(돌연변이) 생성방식 - 테스트 결과의 신뢰성 확보가 목적

소프트웨어 테스트 프로세스의 개요 가. 소프트웨어 테스트 프로세스의 정의
소프트웨어 테스트 프로세스는 제품의 행위, 성능, 견고성이 기대하는 기준에 부합하는 지를 평가하기 위한 프로세스로 검증(Verification) 활동과 확인(Validation) 활동을 핵심으로 함
소프트웨어 테스트 영역에서 품질은 제품에 대한 테스트 활동으로 시작되어 테스트 단계별 활동 내역을 관리하고 테스트 진행 내역에 대해 체계적으로 관리하는 활동인 테스트 프로세스까지 확장 나. 소프트웨어 테스트 프로세스 관리 필요성

필요성 설명 소프트웨어 품질 향상 소프트웨어 품질을 향상하기 위해 산출물 중심의 테스트와 병행하여 프로세스 중심으로 단계별 테스트 활동을 정의하여 관리 최종 소프트웨어 품질을 향상하여 고객 요구사항에 부합하는 제품 생산 제품중심 테스트 보완 소프트웨어 제품중심의 테스트를 소프트웨어 개발 생명주기에 부합하도록 개발 프로세스에 부합할 수 있는 정형화된 테스트 절차를 통해 제품중심의 테스트 보완 Time to Market 소프트웨어 규모와 복잡도가 증가함에 따라 출시 주기도 짧아져서 소프트웨어가 고객이 요구하는 시점에 제공될 수 있으려면 테스트 절차가 정의되고 관리 되어야 함 테스트 품질 향상 테스트 단계별 활동을 정형화 하고 표준화함으로써 조직 및 개발자 간의 편차가 줄어들게 되고 조직 전반의 테스트 품질이 향상

※ 소프트웨어 제품(Product) 평가할 경우 평가모형이 가져야 하는 특성 가. 반복성(Repeatability) : 동일 평가자가 동일 사양의 제품을 평가할 때 동일한 결과 나. 재생산성(Reproducibility) : 다른 평가자가 동일 사양의 제품을 평가할 때 동일한 결과 다. 공평성(Impartiality) : 특정 결과에 편향되지 않아야 함 라. 객관성 2. 소프트웨어 테스트 프로세스 별 활동 및 대표적인 테스트 프로세스 모델 1) 테스트 프로세스 별 활동

단계 활동 테스트 계획 및 통제 단계 테스트 계획 테스트의 목적과 미션을 만족시키기 위해 미션을 검증하고 목적과 활동을 명세 테스트 기법, 테스트 항목, 적용범위, 테스트웨어 등 정의 요구되는 테스트 자원을 정의, 테스트 전략과 정책을 결정 테스트 구현과 실행, 평가를 계획, 종료기준의 결정 테스트 통제 실제 진행사항과 계획을 비교하고 계획의 오차와 진행 상태를 보고 하는 활동 테스트 분석과 설계 테스트에 대한 기본사항(요구사항, 아키텍처, 디자인, 인터페이스) 분석 테스트 조건, 테스트 요구사항, 테스트 항목, 명세, 동작과 구조에 분석에 필요한 기반 구조와 도구를 정의 테스트 구현과 실행 테스트 케이스의 개발과 우선순위화 테스트 데이터의 생성, 테스트 프로시저 작성, 테스트 장치와 자동화 스크립트 작성 테스트 환경 검증 테스트 케이스로부터 테스트 슈트(Test suit) 작성 테스트 케이스 실행, 실제 테스트 결과와 예상 테스트 결과 비교 후 불일치 원인 분석 테스트 종료 기준의 평가와 보고 테스팅 계획에 정의된 종료 기준으로 테스트 로그 비교 종료 기준의 변경 평가 테스트 요약 보고서 작성 테스트 종료 부가적 이슈에 대한 종료 보고서 및 오픈 상태로 남아 있는 변경 기록 확인 테스트 환경, 테스트 기반 구조 정리 및 승인 Lessons learned 분석

※ 테스트웨어 - 테스트를 계획, 설계, 실행하는 테스트 프로세스 동안 생성된 산출물 - 테스트웨어는 테스팅에 사용되는 문서, 스크립트, 입력값, 예상 결과, 시작과 마무리 절차, 파일, 데이터베이스, 환경 그리고 모든 추가적인 소프트웨어 또는 유틸리티를 포함한다 2) 대표적인 테스트 프로세스 모델 TMMi의 개요 가. TMMi(Test Maturity Model integration)의 정의 - 조직의 SW테스트 성숙도를 점검하고 개선방향을 안내하는 모델 - 국제적으로 유일하게 인정받는 SW 테스트 분야 공식 심사 모델 - 테스트 성숙도 모델은 테스트 프로세스 개선과 향상에 중점을 두는 조직 가이드로써 각 테스트 단계에서 수행해야 할 활동들을 기준으로 테스트 성숙도를 측정하기 위해 개발된 모델 - 조직의 개발 최적화를 위해 프로세스를 관리하기 위한 여러 프로세스 모델들이 테스트 프로세스를 포함하고는 있으나 실제 테스트를 위한 정형화된 프로세스가 아님 - 테스트 프로세스 성숙도 모델은 심사모델 및 절차, 심사 도구 및 질문서, 팀 교육 등에 관한 기준을 제시하고 있는 모델 ※ IT 융복합 추세에 따라 SW 적용이 산업 전반으로 확산됨에 따라 SW 테스트의 필요성이 부각되고 있는 가운데, SW 테스트 국제 공인 성숙도 평가모델인 TMMi(Test Maturity Model Integration)에 대한 관심이 커지고 있음 ※ TMMi : SW 테스트 조직의 성숙도를 평가하고 프로세스를 개선하기 위해 개발한 모델로, 국제적으로 인정받고 있는 SW 테스트 분야의 공식 심사모델 ※ SW 및 시스템 공학분야의 대표적인 국제 평가기준인 CMMI(Capability Maturity Model Integration)와 연계된 부분이 많은 것도 TMMi의 장점 나. TMMi(Test Maturity Model Integration)의 구성

CMMi 모델과 유사한 구조로 구성되어 있음
TMMi 성숙도 모델(5단계 모델)

Level 설명 Level1 : 초기(Initial) 테스팅은 정의되지 않거나 테스팅과 디버깅의 한 부분으로 인식되고 조직은 일반적으로 프로세스를 지원하기 위한 안정적인 환경제공이 어려움 조직인력의 능력과 자신감에 의존 테스트 프로세스 미정립, 테스트와 디버깅 차이가 구분되지 않음 Level2 : 관리(Managed) 테스트와 디버깅이 구분되며 테스트가 소프트웨어 생명주기에서 하나의 독립된 단계로 정의되고, 결함 발견 활동의 집중 테스트 정책을 별도로 문서화하거나 품질∙개발 정책의 일부분으로 정의하고 있어야 함 테스트 전략 또는 접근법에 근거하여 테스팅을 하고 있다는 것을 증명 Level3 : 정의(Defined) 테스팅이 개발 생명주기와 통합되는 단계로 레벨2에서 테스팅을 포함하고 개발 되었는지 검증하는 테스트 활동 수행 테스트 프로세스와 소프트웨어 개발 생명주기가 통합되어 있어야 함 별도의 테스트 조직을 갖추고 있어야 하며 레벨2가 프로젝트 레벨에서 내재화 하는 수준이라면 레벨3은 조직차원에서 테스팅을 내재화 하는 수준 Level4 : 관리 & 측정 (Management & Measurement) 발전된 동료검토 활동이 수행되고 있어야 하는데 테스팅 시각에서 볼 때 테스트 케이스를 요구사항 분석 단계부터 설계하고 작성하는 것을 통해 개발 중간 산출물의 결함을 조기에 발견하는 예방적인 테스팅을 의미 테스트를 관리하고 측정하는 단계로 소프트웨어 품질 평가와 매트릭을 이용한 테스트 측정을 통해 테스트를 수치화하고 이를 기반으로 정량적으로 관리하고 있어야 달성 가능 Level5 : 최적화 (Optimization) 결함 예방과 품질제어 활동에 초점, 테스트 프로세스가 정의되고 관리되며, 비용과 효과가 추적되고 감시 테스트 프로세스가 지속적으로 개선되고 조정되며 결함예방과 품질 제어 활동을 수행 이들 활동이 통계적 방법과 다양한 평가 기준에 의해 측정되고 관리자는 지속적인 개선을 유도하기 위해 인프라를 지원하고 동기 부여

대표적인 테스트 프로세스 모델 TMMi와 TPI와의 비교

항목 TMMi TPi 테스트 레벨 하위레벨과 상위레벨 테스팅을 유사한 수준으로 다룸 상위 레벨 테스팅에 보다 집중 성숙도 평가 접근법 조직 차원에서의 성숙도평가 (다섯 가지 레벨로 평가) 각 개별 프로세스의 성숙도평가를 위해 조직의 성숙도평가 (2~4레벨로 프로세스별 차별적 평가) 모델의 태생 (Origin) 학계에서 개발하여 업계에서 발전시킴 시스템 테스팅 전문업체 개발 및 확산 공개정도 Level2, Level3 내용은 공개되어 있고 나머지도 공개 되고 있는 추세 대부분 공개 되어있음 공식레벨 부여 여부 TMMI Foundation에서 2008부터 부여 • 심사원 자격 부여 및 관리 • 심사결과관리 부여 하지 않음 참조모델 (Reference Model) 프로세스(진단)참조모델 (Process Reference Model) 내용(개선)참조모델 (Content Reference Model) 프로세스(진단)참조모델 (Process Reference Model) 핵심영역 간 의존성 핵심영역간 의존성을 정의하지 않음 핵심영역간 의존성 정의

TPI(Test Process Improvement) 개요 및 TPI 모델 구조 가. TPI 개요 − 소프트웨어 테스팅 프로세스 개선 로드맵을 제시해주는 모델 − 소제티(Sogeti)에서 개발한 모델로 테스트 프로세스의 핵심영역(Key Area)을 20개로 나누고, 각 핵심영역별로 2~4레벨로 평가하는 테스트 심사 프레임워크 − 핵심영역은 Check Point를 이용해 평가되고, 핵심영역별로 개선 제안이 존재하여 개선을 지원하는 체제 나. TPI 모델 구조

1) 모바일 애플리케이션 테스팅(Mobility Application Testing) － IDC는 2014년 스마트폰 판매량이 약 5억 대에 이를 것으로 전망 － 스마트폰은 개인적인 용도 뿐 아니라 사무적인 용도로 쓰이고 있으며 스마트폰에 설치할 수 있는 애플리케이션은 이미 수백만 개에 이르고 있음 － 몇몇 애플리케이션은 ERP시스템과 연동한 클라우드 서비스로 이용되고 있음에 따라 데이터 보안이 가장 중요한 핵심 이슈로 등장 － 스마트폰에 탑재된 대부분의 OS는 기능테스트와 통합 테스트는 필수불가결한 요소로 인식 2) TaaS 서비스(Testing-as-a-Service) － TaaS(Testing-as-a-Service)가 IT인프라 투자가 불가피한 상황에서 그 대안책으로서 사용량과 수요가 증가하고 있음 － 오늘날 대부분의 CXO CEO, CIO 등 고위경영층을 통칭들은 TaaS를 △ 비용 절감을 위해 △ 불량률을 낮추기 위해 △ 프로젝트 요구사항 필요한 협력사의 테스트 환경 검증 등의 문제를 해결하기 위한 도구로 인식하고 있음 － 또한 TaaS는 클라우드 테스팅이나 테스트 관리에 이용되기도 함 3) 상호 클라우드 테스팅(Cross cloud testing) － 클라우드 서비스 간의 커뮤니케이션 패턴과 데이터 포맷을 표준화하기 위한 몇 가지 방안들이 있음 － 커뮤니케이션 패턴의 표준화는 이용자가 데이터를 안전하게 지키며, 테스팅 벤더에 대한 신뢰를 얻을 수 있게 하며 또한 끊김 없는 안정성 있는 서비스를 이용할 수 있음 － 이러한 장점들로 벤더들이 머지않아 상호 클라우드 테스팅 실행에 참여할 것으로 예상됨 4) 비즈니스 인텔리전스 테스팅(Business Intelligence Testing): － 비즈니스 인텔리전스 툴은 단지 방대한 데이터를 분석하는 기능뿐만 아니라 비즈니스 인텔리전스 툴이 실시간 데이터 추출, 활용하여 주요 트렌드를 파악, 이를 사용자에게 얼마나 효율적으로 전달하는 것이 매우 중요함 － 이를 위해서는 매우 효율적인 시스템이 요구되며, 비즈니스 인텔리전스 테스팅을 통해 시스템 성능 저하 또는 다운타임(down time)을 유발을 방지함 5) 크라우드 소싱 테스팅(Crowd sourced Testing) － 크라우드 소싱 테스트의 성장세는 이미 업계 전반에 알려져 있으며 IDC는 전통적 아웃소싱이 점차 클라우드 소싱을 위한 테스팅 애플리케이션(웹 애플리케이션, 모바일 애플리케이션 등)과 경쟁구도를 이룰 것이라고 전망함 － 2011년에도 기업들은 글로벌 인재와 다양한 기술들을 얻는데 크라우드소싱 마켓을 선호하는 것으로 나타남 6) 데이터 생성 및 관리 테스트를 통한 테스팅 서비스 수요 촉진(Testing catalyzed through test data generation and management) － 애플리케이션 테스트를 하는 동안 고객의 개인정보는 테스터들에게 노출 되며 이 문제는 기업의 브랜드와 비즈니스에 심각한 문제를 일으킬 수 있음 － 테스트 데이터 관리는 대규모 테스트 계약에 난독처리(obfuscating)하게 하여 테스트 데이터의 활용과 보안을 보장함 － 많은 테스트 업체들은 지금이 데이터를 덮거나 '시험 전용'데이터를 작성해 테스트하는 동안 개인정보보호와 보안을 유지하기 위해 다양한 방법을 연구하고 있음

IT 서비스의 성능 한국IT서비스산업협회는 IT 서비스를 ‘최적의 정보기술을 활용해 조직의 경쟁력을 제고시키고, 해당분야의 업무 및 사업의 부가가치를 제고하며, 정보기술을 기반으로 기존산업과 융합해 새로운 서비스를 창출하는 것’이라고 정의했다. 쉽게 말해 IT 서비스에 대한 성능은 곧 ‘IT 서비스 목표에 대한 달성 정도’를 의미한다. 여기에서 IT 서비스의 목표달성 정도는 다양한 지표를 통해 종합적으로 평가되며, 제공하는 서비스의 목적에 따라 평가지표도 달라진다.여기서 한 가지 짚고 넘어갈 것이 있다. 흔히 성능을 품질과 많이 혼동한다. 하지만 IT 서비스에서의 이 둘은 엄연히 다른 의미를 가지고 있다. IT 서비스 품질은 ISO 9126(소프트웨어 품질에 대한 국제표준)에서 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 등 여섯 가지 항목으로 정의돼 있으며, 소프트웨어 공학에서 정의된 내용을 바탕으로 측정한다. 반면, IT 서비스 성능은 주로 사용자나 고객의 요구사항에 기반을 두고 측정된다. 여러 가지 항목에서 중복되는 것들이 있어 이 둘을 혼용하는 경우가 많다. IT 서비스의 주요 성능 이슈 IT 서비스에서의 주요한 성능 이슈는 사용자, 개발자, 그리고 운영자가 느끼는 성능 요소 등 다양하지만, 결국 시스템 운영 시 장애나 서비스 지연과 같은 현상발생 여부로 귀결된다. 주요 이슈들을 조금 더 구체적으로 정리했다. 표 1. 이슈 리스트

특성 내용 효율성 서비스를 제공할 때 시스템의 자원사용량과 응답시간이 보장되는가? 안정성 장시간 운영 시 일정한 수준의 서비스가 제공되는가? 가용성 과부하 상태에서 서비스가 중단되지 않고 유지되는가? 신뢰성 서비스의 기능상 오류가 발생하지 않고 지속적으로 정상 기능을 수행하는가? 이식성 시스템 변경 시에도 일정 수준의 서비스가 제공되는가? 장애조치 장애 발생 시 신속하게 조치할 수 있는가? 용량계획 향후 서비스 사용량에 따라 시스템의 용량 계획을 어떻게 세워야 하는가?

이 외에도 많은 이슈가 존재하지만, 대표적인 여섯 가지만 살펴본다. 효율성을 측정하기 위해서는 사용자들이 IT 서비스를 요청해서 처리할 때의 시스템의 자원사용량과 응답시간을 측정한다. 또 자원사용량을 어느 정도 사용하는 상황 하에서 IT 서비스의 응답시간도 확인해야 한다. 이론적으로는 자원사용량이 100%에 도달하기 전까지는 응답시간의 지연현상이 발생하지 않는다. 하지만 자원사용량이 높은 경우 시스템에 여유가 없기 때문에 응답시간 지연현상이 자연스럽게 나타나게 된다. 이 경우 시스템의 용량에 비해 부하가 높게 들어오는 것이므로 문제가 되지 않는다. 하지만 자원 사용량은 낮으면서 목표 처리량에 비해 불안정한 응답시간이 나타난다면 반드시 그 원인을 분석하고 해결해 효율성을 확보해야 한다. 안정성을 측정하기 위해서는 오랜 시간 IT 서비스를 요청해 시스템의 CPU나 메모리 사용량이나 세션 연결 및 해제, 생성되는 스레드 개수 등의 추이를 분석한다. 장시간 서비스가 제공되더라도 메모리 누수나 CPU 이상 사용, 유령 세션 발생, 혹은 스레드의 무한 증식 등이 발생하면 안 된다. 하지만 만일 장시간 운영했을 때 앞서 언급한 현상들이 발생한다면 심각한 응답시간의 저하와 시스템 다운 등 장애가 발생할 수 있다. 안정성 측정은 일정 수준의 부하 상황에서 시간과 자원 사용량이 어떤 관계도 갖지 않음, 다시 말해서 시스템이 시점과 상관없이 일정한 성능으로 유지되는 것을 말한다. 가용성은 시스템의 용량에 버금가거나 다소 높은 수준의 부하 상황에서 시스템이 다운되거나 서비스가 중단되는 현상, 다시 말해 실패한 서비스 비율(Fail Rate)을 측정한다. 신뢰성은 테스트 데이터에 상관없이 목표 시간 이내에 올바른 결과 혹은 오류를 출력하는 것으로 측정한다. 다양한 테스트 데이터를 준비한다면 그만큼 정상적으로 처리된 요청과 잘못 보낸 요청들의 응답시간을 다양하게 측정할 수 있다. 장애조치와 용량계획은 앞서 설명한 항목과는 좀 다르다. 장애조치는 운영 프로세스와 관련된 내용으로 장애를 판단하는 주요 요소는 서비스의 연속성이다. 서비스의 연속성은 응답시간을 기준으로 해 판단하는 경우가 많다. 응답시간이 느려지거나 시스템이 요청에 대해 응답을 못하는 경우에 이를 분석하는 것이 아니라 서비스를 재개시키는 과정을 말한다. 용량계획은 서비스의 처리 복잡도와 사용량 추이를 분석해 시스템의 임계 성능과 비교한 시스템의 증설계획을 세우는 것을 말하는 데, 이는 시스템의 자원사용량과 응답시간의 상관관계를 통해 근거자료를 만들 수 있다.지금까지 언급했던 여섯 가지 항목들이 만족된다면 안정된 IT 서비스를 제공할 수 있을 것이다. IT 서비스의 성능 지표 앞서 IT 서비스의 성능을 목표에 대한 달성 정도라 표현했다. 그렇다면 과연 성능 목표란 어떤 것들을 말하는 것일까? 먼저 성능 테스트를 수행할 때 측정하는 지표를 살펴보자(표 2 참조). 표 2. 대표적인 IT 서비스 성능 지표

항목 정의 (단위) TPS Transaction Per Second. 시스템이 초당 처리하는 업무 수 (TPS) 평균 응답시간 클라이언트가 서비스를 요청하고 응답을 받기까지 걸리는평균적인 소요시간(초) 최대 응답시간 클라이언트가 서비스를 요청하고 응답을 받기까지 걸리는최대 소요시간(초) CPU 사용량 부하 상황에서 서버에서 IT 서비스를 제공할 때의 CPU사용량(%) 메모리 사용량 부하 상황에서 서버에서 IT 서비스를 제공할 때의 메모리사용량(%) Fail Rate 전체 요청 건수 대비 오류 발생 건수(%) Execution TimePerDataVolume 전체 데이터 크기에 따른 IT 서비스 처리 시간- OLAP 서비스의 응답시간 동시 사용자 같은 시간대에 같은 IT 서비스를 요청하는 사용자 수(명) 처리량(Throughput) 단위 시간 당 대상 시스템에 의해서 처리되는 요청 건수(bytes/sec) 네트워크 사용량 초당 네트워크에서 전송되는 패킷이나 비트수(PPS or BPS)

익숙한 지표도 있고, 생소한 지표도 있다. 지금부터 나열한 항목들을 조금 더 자세하게 알아본다. TPS(Transaction Per Second)에 사용하는 트랜잭션은 사전에 정의된 업무단위이다. 다시 말해 IT 서비스를 제공할 때 시스템이 처리하는 부하량이 곧 TPS다. 보통 시스템의 부하상황을 말할 때 그 기준이 되는 지표를 TPS로 삼는 경우가 많다. 응답시간은 평균과 최대, 그리고 간혹 표준편차 혹은 90% 응답시간 등을 지표로 삼는다. 이렇게 지표를 삼는 이유는 응답시간이 크게 흔들려서 최소 응답시간과 최대 응답시간이 크게 차이나거나, 서비스가 안정적으로 이뤄지고 있다고 판단하기는 힘들지만 평균만을 기준으로 볼 때 크게 차이가 없는 경우가 있기 때문이다. 응답시간은 사용자가 IT 서비스의 성능을 가장 직접적으로 느끼는 지표이기에 자원 사용량과 함께 반드시 확인해야 한다. 자원사용량은 시스템의 CPU나 메모리의 사용량을 뜻한다. 자원사용량은 IT 서비스가 제공되는 동안 시스템이 얼마나 효율적으로 일하는지를 판단하는 지표이며, 동시에 IT 서비스를 제공함에 있어서 안정성을 판단하기 위한 지표이다.Fail Rate는 전체 서비스 요청 대비 한 오류 발생률을 말한다. 일반적인 상황에서 어떤 IT 서비스건 내/외부적인 요인으로 정상적인 응답을 하지 못하는 경우가 발생한다. 이는 소프트웨어의 테스트나 시스템 테스트만 가지고는 밝혀내기 힘들다. 과부하 상황이 발생할수록 Fail Rate가 올라갈 확률이 높아지는데, 대학의 수강신청이나 프로야구 포스트 시즌 예매 때의 시스템 상황을 떠올리면 쉽게 이해할 수 있다. Fail Rate는 IT 서비스의 전반적인 안정성과 가용성, 그리고 서비스의 신뢰성을 판단하는 중요한 지표가 된다. Execution time per data volume은 데이터의 양에 따른 수행 시간을 의미한다. 주로 DBMS의 성능과 관련이 있지만 특히 OLAP 업무의 성능을 판단할 때 중요하게 사용되는 지표이다. 최근에는 대용량 DB를 기반으로 한 IT 서비스가 대세를 이루고 있기 때문에 하루에 쌓이는 DB의 양도 점점 많아진다. 따라서 Execution time per data volume은 특히 더 관심을 가지고 자세하게 살펴보아야 하는 중요한 지표이다. 이 지표는 백업과 파일 시스템의 구성을 효율적으로 하기 위해서 데이터의 양과 접근패턴을 참고하는 경우가 많다. 동시 사용자의 경우에는 시스템의 용량과 관계된 지표로, 해당 IT 서비스 산업의 추세를 판단할 수 있는 좋은 지표이다. 왜냐하면 성능과 관련한 것도 중요한 지표이지만 동시 사용자는 고객 수와 밀접한 관계가 있기 때문이다. 또 시스템이 한 번에 포용해야 하는 사람의 수이기 때문에 시스템에 필요한 최소 세션 수를 판단하고 시스템의 적정 부하량을 예측할 때 참고하는 지표이다. 처리량과 네트워크 사용량은 시스템 전체에 해당 IT 서비스의 요청이 들어왔을 때 시스템이 수행하는 작업의 총량을 뜻한다. 트랜잭션이 똑같이 1이라고 해도 그 비중과 업무의 복잡도에 따라 처리하는 작업이나 데이터의 양이 다르기 때문에 반드시 확인해야 한다. 또한 네트워크 사용량과 처리량은 직접적인 관계에 있으며 보통 여러 시스템이 하나의 네트워크에 연결돼 있는 경우가 많기 때문에, 하나의 IT 서비스로 인해 여러 서비스들에서 장애가 발생되는 것을 방지하기 위해서도 확인해야 하는 지표이다. 지금까지 IT 서비스의 주요 지표들에 대해 살펴봤다. 테스트를 수행하다 보면 정상적인 상황에서는 항상 상관관계들이 존재한다. 이 상황에서 벗어난다는 것은 시스템 어느 한 쪽에서 문제가 있다는 말이 된다. 지금부터 정상적인 상황에서 이들 사이에 존재하는 상관관계를 알아보겠다. 성능 지표들 사이의 상관관계 성능 지표를 측정할 때, 전제가 되는 것이 ‘부하 상황’이다. 다시 말해서 특정 TPS에서의 다른 성능지표 변화를 측정하고 이들의 상관관계를 통해 진단한다. 가장 대표적인 상관관계가 TPS와 응답시간, TPS와 자원사용량이다. 이들의 상관관계는 Little’s Law와 Response Time’s Law 등을 통해 정리할 수 있다. 공식을 정리하면 (그림 1), (그림 2)와 같이 그래프로 TPS와 다른 지표간의 상관관계를 나타낼 수 있다. 이론적으로는 가장 이상적인 경우는 TPS가 높아질수록 시스템의 자원이 많이 사용되면서 그에 따라 일정한 수준의 응답시간을 나타내는 것이다. 그림 1. 이상적인 TPS와 성능 지표 간 상관관계 그래프

하지만 실제 TPS를 증가시켜 자원사용량과 응답시간을 측정해보면 자원 사용량의 경우에는 급격하게 증가하다가 일정 수준에서 증가폭이 줄어드는 것을 확인할 수 있다. 응답시간은 천천히 증가 혹은 일정 수준을 유지하다가 특정 TPS 이상에서 급격히 증가한다. 그림 2. 실제 측정 시 TPS와 성능 지표 간 상관관계 그래프

이처럼 응답시간이나 자원 사용량의 변화가 급격하게 이루어지는 지점을 임계점이라고 한다. 시스템의 임계 수준 이상의 부하가 들어오게 되면, IT 서비스의 성능은 급격히 떨어지며 심한 경우에는 시스템이 다운되는 현상이 발생하기도 한다. 이처럼 성능 지표들을 측정할 수 있는 방법 중 다양한 상황을 발생시켜 여러 현상을 볼 수 있도록 해 IT 서비스의 성능을 진단하고 이슈를 해결할 수 있는 방안을 도출해 낼 수 있는 것이 성능 테스트이다. 성능 테스트의 정의와 종류 과거에는 코딩작업의 일부로, 프로그램이 정확하게 기능을 수행하는 지 파악하는 과정으로 테스트가 수행됐다면, 현재에는 구현된 시스템과 고객의 요구사항이 일치하는 지를 파악하는 의미로 수행된다. 더불어 IT 서비스를 제공하는 기업들은 소프트웨어 및 시스템 테스트를 통해 그들이 제공하는 서비스의 품질을 측정하고 개량해, 양질의 IT 서비스를 유지하려 한다. 성능 테스트는 위에서 설명한 테스트 활동의 한 종류로 ‘IT 서비스의 목적과 성격에 따라 성능 목표를 설정하고 다양한 방법으로 측정해 목표 성능을 확보하는 과정’이다. 마치 성능 테스트는 작가가 하나의 글을 쓴 뒤 독자들에게 보이기 전 퇴고하는 것과 같다. 따라서 성능 테스트는 최종적으로 고객에게 완료 보고의 역할을 하는 인수 테스트 직전까지 진행되기 때문에 전체적인 IT 서비스를 꼼꼼하게 진행해야 한다. 테스트 과정은 IT 서비스의 품질을 확보하는 과정이면서 동시에 서비스 운영 시 발생할 수 있는 장애 상황을 야기 시킬 수 있는 여러 결함을 사전에 파악해 제거하거나 조치할 수 있는 방안을 준비할 수 있게 하는 중요한 과정이다. 성능테스트는 다양한 기준으로 구분할 수 있지만, 단계에 따라서 단위성능 테스트, 통합성능 테스트, 임계성능 테스트, 인프라 테스트 등으로 구분할 수 있다. 이 구분은 일반적인 테스트 단계와 동일하다. 각 테스트 별 의미를 살펴보면, 성능 테스트에서 단위라고 하는 것은 사전에 테스트 관계자들이 동의한 업무를 의미한다. 통합 성능 테스트는 단위 업무들의 비중과 중요도, 부하모델 등을 계산해 실 환경과 유사하게 부하를 발생시키는 테스트이다. 임계 테스트의 경우에는 가용성이나 안정성 등에 대한 검증 작업을 수행할 수 있으며, 인프라 테스트는 부하 상황에서 장애와 같은 특수 상황을 임의로 발생시켜 시스템의 이상 유무를 검증하고, 이에 대한 적절한 조치를 어떻게 취해야 하는지를 확인하는 테스트이다. (표 3)에서 각 단계별 테스트 특징을 정리했다. 표 3. 단계별 성능 테스트 특징

단위 성능 테스트 - 개별 단위 : 애플리케이션의 목표 성능 만족 여부 측정 - 일반적으로 애플리케이션 튜닝과 동시에 진행됨 - 통합 테스트 수행 시 발생할 수 있는 업무별 병목사항 사전 제거 - 단위 업무의 업무 부하 측정 - 통합 성능 테스트 수행환경 점검
통합 성능 테스트 - 서비스 사용 패턴에 따른 부하 상황에서의 목표 성능 만족 여부 측정 - 시스템 용량의 업무 부하 대비 적정 여부 확인 - 시스템 아키텍처 별 성능 검증 및 튜닝 포인트 분석
임계 성능 테스트 - 서비스 사용자나 업무량의 증가 추이 분석 결과와 연계해 시스템 증설 계획수립 - 시스템의 자원 사용량 증가에 따른 가용성 및 안정성의 보장 여부 검증 - 시스템의 자원의 증설 우선순위 결정(CPU, 메모리, 네트워크, 스토리지, DB 등) - 시스템의 티어의 증설 우선순위 결정(서버, 미들웨어, DB, 스토리지, 네트워크 등)
인프라 테스트 - 예상 장애상황에서의 처리 과정 검증 - 필요에 따라 특정 설정 시 나타나는 현상에 대한 검증 - 가용성 검증

기대 효과 단순하게 시스템이나 소프트웨어의 성능 테스트가 아닌 IT 서비스를 기준으로 성능 테스트를 준비하고 수행하는 것은 매우 어렵고 귀찮은 일이다. 이처럼 귀찮고 까다로운 과정을 거쳐야 하는 이유는 그만한 가치가 있기 때문이다.우선 서비스 안정화 기간을 줄이면서 동시에 안정적인 IT 서비스를 제공할 수 있다. 성능 테스트는 운영환경과 비슷한 상황을 만들어 문제점을 파악할 수 있기 때문에 다양한 현상이나 장애에 대한 답을 미리 구할 수 있고 조치방안도 마련할 수 있다. 또한 용량계획을 세울 수 있는 근거와 용량증설에 대한 우선순위 근거를 제공해 시스템 관리를 보다 정확하게 할 수 있다. 시스템의 성능지표들과 부하량의 추세를 비교/분석해 어느 시점에서 시스템 운영상 이슈가 발생할 수 있을 지를 예상할 수 있다.그리고 조직의 기술수준을 향상시킬 수 있다. 성능 테스트를 준비하는 과정부터 이슈들을 도출하고 이를 해결하는 과정을 시뮬레이션 시켜봄으로써, 그와 관련된 분야에 대한 지식을 눈으로 직접 확인해보면서 각 튜닝 포인트 간의 상관관계들을 확인할 수 있기 때문이다. 추가적으로 이를 사내 지식 시스템 등으로 활용하면 그 활용폭이 더욱 넓어질 수 있다. 그 외에도 성능 테스트를 수행함으로써 얻을 수 있는 효과는 더 많다.지금까지 IT 서비스의 성능과 테스트에 대해 간단하게 소개했다. IT 서비스를 개발하거나 운영할 때에도 표준화된 프로세스가 있듯, 성능테스트를 수행할 때도 반드시 거쳐야 하는 프로세스가 존재한다. 다음 기고에서는 보다 수준 높은 IT 서비스를 제공하기 위해 실제 성능 테스트를 어떤 순서로 어떻게 수행하는지 알아보겠다.

SW공학 - SW개발의 기획부터 유지보수에 이르는 전체 과정에 대한 기술, 인력, 프로세스 등을 체계적으로 관리하는 기술 - SW공학 기술을 적용하면 개발 생산성과 품질향상을 꾀할수 있어 글로벌 SW 기업들은 필수적으로 적용하고 있음 SW공학 기술 적용 성과 - CMMI 및 SP(소프트웨어프로세스)품질 인증 심사 획득 가능 - SW품질 향상 적용, 품질 개선은 물론이고 코드 재사용률을 높임 - 고객 요구사항 및 이슈에 빠르게 대응 - 테스팅, 피드백 운영체계 확보로 고객 만족도 향상 - SW통합 개발 프로세스를 개선하고 코드 품질을 향상 시킴

아래의 코드에 대한 테스트케이스(Test Case)를 작성하는 과정에 대하여 다음 질문에 답하시오

핸드폰에 저장된 앨범에 수록된 음악을 순차적으로 듣는 기능 // index = 앨범내에 수록된 곡 순서 unsigned int end = 4; SelectPlayIndex(index); // 듣기 기능 선택(1) do { switch(CheckFileType(index++)) (A) // 음원 파일이 정상이면 index값을, 비정상이면 "0"을 Return { ~end :PlayMusic(index); (2) end :PlayMusic(index); stopPlay = YES; (3) 0 :DisplayErr("음원 재생이 실패하엿습니다. 재생을 중지하시려면 언제든지 "종료"버튼을 선택하실 수 있습니다."); (4) } } while(index != end && stopOption != YES) (B) StopPlay(); (5)

(1) 제어 흐름도를 작성하시오 (2) 테스트 경로를 나열하시오 (3) 테스트 경로에 따른 테스트케이스를 작성하시오 1. 테스트 케이스 유형 및 화이트박스 테스트케이스의 개요 가. 테스트 케이스 유형

테스트케이스는 프로그램 동작 상태 조사를 위하여 프로그램 내부구조를 고려하지 않는 블랙박스 유형의 테스트케이스와 코드에 기반한 화이트박스 테스트케이스로 분류가 가능 나. 화이트박스 테스트케이스의 종류 및 적합성 기준

종류 적합성 기준 기준설명 제어흐름 시험 Statement coverage criterion (문장 적합성) 프로그램을 구성하는 모든 문장들이 최소 1회 이상 실행 되도록 테스트 데이터 선정 Branch coverage criterion (분기 적합성) 조건문의 결과가 참/거짓이 되는 경우를 최소한 한번 이상 실행하게 하는 데이터 선정 Condition coverage criterion (조건 적합성) 해당 조건식이 기본 관계식으로 이루어 진 경우 참/거짓이 되는 경우를 테스트 가능한 집합으로 선정 자료흐름 시험 All-definitions 적합성 프로그램에 나타난 모든 변수들의 정의들이 최소한 한번은 참조되어야 하는 기준 All-Uses 적합성 변수의 정의가 사용되는 모든 지점까지 경로를 최소한 한번은 실행할 수 있는 테스트 데이터 기준 All-du-경로 적합성 변수의 각각의 정의로부터 변수가 참조되는 노드까지의 모든 경로를 테스트

다. 화이트 박스 테스트의 제어흐름 시험의 작성 기준

단계 작성방법 작성기준 제어 흐름도 작성 코드기준 순서도 작성 Statement, Branch, Loop 요소 식별 테스트 경로 작성 제어 Graph로 변환 Node와 Edge로 제어흐름 변환, 방향성 있는 Path 결정 테스트 케이스 작성 테스트 경로별 변수결정, 변수에 대한 입력값, 기대값 결정 Path 별 오라클 결정

제어 흐름도의 작성
프로그램 구조를 분석한 제어 흐름도
제어흐름도에 의거한 테스트 경로 선정
Switch 문에 의한 조건 검증 테스트 경로
McCabe 회전 복잡도를 계산해 보면 V(G) = 화살표 수(A) - 노드 수(N) + 2 만큼의 기본 경로 테스트 케이스가 도출되어야 함
위의 예에서 화살표수(9) – 노드수(7) + 2 = 4 개의 테스트 케이스 도출 1) Path 1 : 1->A->2->B->A->3->B->5 2) Path 2 : 1->A->2->B->A->4->B->5 3) Path 3 : 1->A->3->B->5 4) Path 4 : 1->A->4->B->5
테스트 경로에 따른 테스트 케이스 작성 가. Path 1

나. Path 2

다. Path 3

라. Path 4

화이트박스 테스트케이스 작성시 고려사항
화이트박스 테스트케이스는 프로그램 논리 흐름도에 기반한 논리구조를 기초로 문장검증, 선택검증, 경로검증, 조건검증 을 고려한 테스트케이스 작성
테스트케이스 설계시 입력값, 예상 출력(기대)값의 정의
프로그래머는 자신의 프로그램 테스트 금지
테스트 결과의 철저한 분석 및 재사용을 위한 자산화는 필수

다음은 소프트웨어 결함을 식별하고 품질을 확보하기 위해 필요한 시험데이터이다. 가장 적절하지 않은 것은? 4 ① 입력항목 x값이 <0~100>사이어야 만족하는 경우에, 시험 데이터로 x<0, 0?x?100, x>100 준비 ② 입력항목이 <학위>인 경우, 시험 데이터로 <학위없음>, <학사, 석사, 박사>, <3개 이상의 학위들> 준비 ③ 입력항목이 <성별>인 경우, 시험 데이터로 <남자>, <여자>, <중성> 준비 ④ 코드가 cs 로 시작하는 전산학과 수강과목코드가 입력항목인 경우, 시험 데이터로 , (단, xxxx : 0000 ~ 9999) 준비 4 번 - 유효 데이터뿐만 아니라 유효 하지 않는 데이터도 시험 데이터로 생성해야 함.

오른쪽 프로그램을 화이트 박스 테스트 작업에 의해 검증하고자 한다. 모든 수행 동작에 대해 신뢰성을 보장하고자 한다면 테스트 사례의 최소수는 얼마가 되어야 하는가? (단, 테스트 사례는 변수 w, x, y, z 값의 조합이다) - 화이트 박스의 모든 논리적 경로를 파악하는 문제임. 일반적으로 if a>b 의 문은 테스트 경우가 2가지 임. - 화이트 박스의 모든 논리적 경로를 파악하는 문제임. 일반적으로 if a>b 의 문은 테스트 경우가 2가지 임. - 문제 설명 if의 조건경우의 수변수의 조합변수 조합의 수비고w > xT F(w, x)2w > yT F(w, y)2w == xT F(w, x)1false의 부분은 첫 번째의 w > x에 포함되므로 변수 조합의 수는 1이 됨y > z (y < z 포함)T F(y, z)2w > zT F(w, z)2합계9

소프트웨어 보안 테스팅 - 제품의 안전한 구현을 확인하여, SW 릴리즈된 후에 소비자나 악의적 사용자에 의해 보안결점들(security flaws)이 발견될 가능성을 미리 줄이기 위한 테스팅. SW 보증활동
SW 제품이 배포되기 전에 그 제품의 강건성(Robustness)과 보안성을 확인하여 보안 취약점들을 예방하기 위한 테스트
SW 보안 테스팅 분류

구분 내용 정적 분석 (static analysis) 코드를 실행하지 않고 주어진 코드 수준에서 취약점이나 약점을 탐지하고 이를 보고하는 기술 동적 분석 (dynamic analysis) - 실행 기반으로 취약점을 파악하는 기술로 소스코드가 주어지지 않아도 적용 가능 - 실제 실행을 통해서 입력에 대한 출력의 반응을 살피고 분석하여 발생 가능한 보안 취약점을 찾아내는 방법

SW 보안 테스팅 방법

구분 내용 위험 분석 (risk analysis) - 보안 요구사항을 검토하고 보안 위험들을 식별하기 위해 설계 단계에서 수행 - 위협 모델링(Threat modeling)은 SW의 위협과 취약점들을 식별하기 위해 사용되는 체계적인 가정 - 설계자는 잠재적 취약점들의 완화전략(mitigation strategy)을 개발하고, 한정된 자원과 노력을 시스템의 가장 위험한 부분에 집중 정적 분석 코드 검토 - 주로 구현단계에서 소스 코드의 보안 약점을 수동으로 검사하는 과정 - 파악 가능한 이슈는 병행성 문제, 결점이 있는 비즈니스 로직, 접근제어 문제, 백도어나 논리폭탄 등의 악의적 코드 등 자동화된 정적분석 - 구현단계에서 SW를 실행하지 않고, 정적 분석 도구를 사용하여 코드분석 - 정적 분석 도구는 버퍼 오버플로, 부정확한 라이브러리 사용, 타입 체킹 결점 등과 같은 언어 규칙 위반을 탐지하는데 효과적임 퍼즈 테스팅 (fuzz testing) - SW의 취약점을 동적으로 분석하고 테스트하는 일력의 기법 - SW에 랜덤 데이터를 입력함으로써 SW의 조직적인 실패를 유발시켜 발생되는 예외, 오류 등을 분석하고 보안 취약점을 찾아내는 테스팅 기법 - 블랙박스(black box) 퍼징과 화이트박스(white box)퍼징으로 분류 가능 취약점 스캐닝 - 알려진 취약점과 연관된 입출력 패턴을 찾기 위해 실행 애플리케이션을 스캔하며, 알려진 취약점에 관련된 패턴, 즉 시그니처(signature) 매칭방식으로 검색 - 취약점 패턴은 백신프로그램에서 사용되는 ‘시그너처’, 또는 자동화된 소스코드 스캐너에서 사용되는 ‘위험한 코딩 구성체’들과 유사 침투 테스팅 (모의해킹) - 블랙박스 테스팅 또는 윤리적 해킹(ethical hacking)으로 알려져 있으며, 대상 애플리케이션 자체의 내부 작용이나 동작에 대해 알지 못한 채로 보안 취약점을 찾기 위해 원격으로 그 애플리케이션을 테스팅 - 주어진 공격을 성공적으로 견뎌내는지 또는 공격을 견디지 못할 때 어떻게 동작하는지 관찰하고 수년 동안 네트워크 보안을 테스트하기 위해 사용된 일반적인 기법

탐색적 테스팅 <문서화 정도와 지적 능력의 활용 정도에 따른 비교>

탐색적 테스팅은 테스트 케이스 문서를 최소화 하지만 그 정도에 따라 공식적(테스트 케이스 기반) 방식으로 확장할 수 있음
테스트 케이스가 많아질수록 테스트할 시간은 상대적으로 줄어들고 공식적이게 되며, 반대로 테스트 케이스가 줄고 탐색적 정도가 늘어나면 상대적으로 테스트할 시간이 늘어나며 비공식적 임 <테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교

테스트 케이스 기반 테스팅 탐색적 테스팅

테스트가 먼저 설계되고 기록된다. 나중에(때에 따라) 다른 테스터가 이를 수행한다 테스트가 설계됨과 동시에 수행된다. 테스트가 반드시 기록되어야 하는 것은 아니다. [비유]준비된 연설을 하는 것과 같다. 테스트는 미리 착안된 생각에 따라 수행된다. 대화를 하는 것과 같다. 테스트는 아이디어를 반영하고 생각을 발전 시키는 방향으로 수행된다. 테스트의 실행을 관리하는 것이다. 테스트 설계를 향상 시키는 것이다. 테스트 실행을 시작하기 전에 테스트 케이스를 작성한다. 프로젝트 기간 내내 테스트 계획/설계와 실행을 반복한다. 테스트 문서 작성, 검토에 많은 에너지를 소비함으로써 테스트의 효율성이 감소하는 경우가 있다. 테스트 문서 작성, 검토에 대한 필요성을 최소화하여 보다 많고 복작한 테스트에 상대적으로 많은 노력 투자가 가능하다. 테스터 간의(특성, 능력) 차이를 제거하려는 노력 테스터 간의(특성, 능력) 차이를 십분 활용하려는 노력 테스터가 아닐 수 있는 테스트 설계자가 테스를 설계한다. 테스트 설계자일 수 있는 테스터가 테스트를 설계한다. 완벽하게 한번에 테스팅을 수행한다. 점진적이고 주기적으로 테스팅을 수행한다.

<리스크 기반 차터 설계>

리스크 분석 결과 제품의 리스크가 높은 기능에는 테스트 차터를 많이 생성하고 리스크가 낮은 낮은 기능에는 테스트 차터를 적게 생성하여 테스트를 수행
리스크가 높은 부분에 테스트 차터를 많이 수행함 <리스크 기반 전략에서의 탐색적 테스팅 접근법 활용>
테스트 전략 수립 시 제품의 리스크가 가장 높은 곳에 탐색적 테스팅을 추가하였고 그 다음 높은 곳에는 선택적으로 탐색적 테스팅을 추가
그 다음 높은 곳에는 선택적으로 탐색적 테스팅을 추가 <탐색적 테스팅 기대효과>
경험적 테스팅을 체계화 시킬 수 있음
테스트 케이스를 작성하는 시간을 줄여 보다 많은 테스를 실행할 수 있음
테스터 또는 테스트 엔지니어의 역량을 월등히 향상시킬수 있음
적은 테스트 인력으로 많은 테스트를 수행할 수 있음
명세가 거의 없고 시간이 부족한 경우 테스트를 효과적/효율적으로 수행할 수 있음

가. recovery testing : 여러가지 방법으로 소프트웨어 장애가 일어나도록 한 후 복구가 적절히 수행되는지 검사하는 시스템 테스트를 말함 나. sensitivity testing : 유효한 입력에 소학는 데이터 조합이 불안정하거나 부적절한 프로세싱을 발생시키는 경우를 찾는 테스트를 말함 다. deployment testing : 동작할 각 환경이나 소프트웨어를 검사한다. 또한, 모든 설치 절차, 고객이 이용하는 특별한 설치 소프트웨어, 최종 사용자에게 소프트웨어를 소개하는 모든 문서들을 검사함

준거성 테스트(Compliance Test)와 실증적 테스트(Substantive Test) 개요 가. 정의 1) 준거성 테스트(Compliance Test) : 내부 통제가 문서화 자료에 명시된 바대로 또 경영자의 의도대로 이행되고 있는가를 판단하기 위한 감사 테스트 2) 실증적 테스트(Substantive Test) : 활동 또는 거래들의 완전성, 정확성 또는 그 존재성에 대한 감사 증거를 수집하기 위해 설계되는 세부활동 및 거래에 대한 테스트 또는 분석적 조사 테스트 나. 활용 1) 정보시스템의 위험평가 및 정보시스템 감리 2) 정보보호 감사
테스트 개념도

나. 준거성 테스트와 실증적 테스트의 기술요소

구분 내용 준거성 프로세스 준수 - 과정심사로서 프로세스 심사 측정(CMMi, SPICE, ITIL) - 성숙도, 질의 및 면담 실증적 증거수집 V&V, 동시감사, 면담, 설문기법, 성능검사 증거평가 - 자산보호 및 자료 무결성 평가 기법 - 효과성 평가기법 - 효율성 평가기법 절차 감리위험->과정심사(준거성 시험) : 질의 및 면담->제품심사(실증시험) : 분석적절차+상세테스트

테스트 수행시 고려사항 가. 정보시스템의 프로세스 및 제품에 대한 평가에서 프로세스에서 제품으로의 평가(감리)요구 증대에 따른 대응 필요함 나. 준거성 시험에서 문제점이 작을 경우에는 실증적 시험의 범위 축소 가능하며 준거성에 문제가 많을 경우에는 실증적 시험에 더 많은 비중을 두어야 함

소프트웨어 테스트 케이스 1) 테스트 케이스의 의미
특정 조건 하에서 관련 요구사항의 만족 여부를 확인하기 위해 필요한 입력 값과 예상 결과 값으로 구성됨.
시험을 수행하기 위해 기본이 되는 문서화된 항목.
직접 시험을 수행하는 근간, 시험을 수행했다는 증거, 시험이 커버하는 범위 표현.
측정 가능한 상태에 대한 정보, 조건, 이벤트, 입/출력 값을 포함하는 데이터로 구성
테스트케이스는 테스트 입력 값, 테스트시나리오, 그리고 예상 값 2) 테스트 기법
명세 기반 테스트 기법은 소프트웨어 기능 명세로부터 테스트케이스를 생성하는 기법. 주어진 명세(일반적으로 모델의 형태)를 빠뜨리지 않고 테스트 케이스화 하는 것을 의미하고 해당 테스트 케이스를 수행해서 중대한 결함이 없음을 보장하는 것
코드 기반(화이트 박스) 테스팅은 구현된 코드로부터 테스트케이스를 생성하는 기법. 소프트웨어나 시스템의 코드와 구조를 중심으로 테스팅 하는것
캡처(Capture) 기법은 시험 하고자 하는 프로그램을 사용자가 시범적으로 사용하고 이때 사용 시나리오를 기록함으로써 테스트케이스를 생성하는 기법
상태 기반 테스트 기법 : 상태를 가지는 프로그램을 대상으로 하는 시험기법으로, 입력값과 상태를 고려하여 시험 데이터를 생성
블랙박스(명세 기반) 기반 테스트 케이스 작성 1) 테스트 케이스의 설계 절차

2) 테스트 케이스의 작성 <사례> 식품점의 전산화를 위한 모듈이 식료품의 이름과 킬로그램(Kg)으로 표시된 무게를 입력 받는다. 품명은 영문자 2자리에서 15자리까지 구성되고, 무게는 1에서 48까지의 정수로 구성된 값이다. 무게는 오름차순으로 입력된다. 품명이 먼저 입력되고 다음에 쉼표가 따라오고, 마지막으로 무게 값의 리스트가 나온다. 쉼표는 각 무게를 구별하기 위하여 쓰인다. 입력에 빈 칸이 나오면 무시된다

테스트 케이스를 작성해야 하는 이유
테스트를 실행하는 과정에 부딪히게 되는 많은 문제들은 테스트 케이스 설계의 미흡함에서 발생함.
테스트 기술 없이 직관만으로 테스트 대상을 분석하면 시간과 인력의 낭비를 가져옴.
정확한 테스트와 요구사항이 잘 반영되었는지 확인 하기 위해서는 테스트 케이스를 작성하여 관계자들과 검토 과정을 걸쳐야함.
테스트 케이스 작성시 주의 사항
테스트 케이스 설계는 테스트 수행 전에 이루어져야 하며 이상적으로는 시스템 개발 초기에 작성되어 시스템 디자인과 요구사항 정의에도 테스트 케이스 설계가 반영되어야 함.
테스트 케이스의 설계시 주의 할 사항은 작업의 마감시간, 불충분한 자료, 자주 변경되는 요구사항, 비협조적인 개발자와 고객간의 관계로 소홀히 작성되거나 생략되면 안됨.
테스트 케이스 수행자와 개발자가 다를 때 원활하지 못한 의사소통으로 잘못된 결과를 얻을 수 있으므로정확한 의사소통이 필요
너무 많은 테스트 케이스를 작성하는 경우 테스트가 원활하게 진행되지 않을 수 있으므로 중요하고, 꼭 필요한 사항들은 별도의 테스트 케이스는 작성하여 진행하는 것도 좋음.
테스트 진행은 고객과 설계자가 진행하는 경우 명확한 예상값을 입력 분쟁을 사전에 방지

● 분류 트리 기법(Classification Tree Method) 소프트웨어의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계 하는 기법이다. 트리구조를 시각화 하여 테스트 케이스를 설계하므로 불필요한 중복 및 누락을 회피할 수 있다. [예제]

위의 표 만들기 구조를 분류 트리 기법을 적용하여 분석하면 아래와 같이 시각화 하여 나타낼 수 있다

<분류 트리 기법 예제>

● 상태 전이 테스팅(State Transition Testing) 시스템의 모든 입출력 상태를 식별하고, 도달 가능한 모든 상태의 입력 조합을 포함 하는 상태 전이 테이블을 정의한 후, 테스트 케이스를 설계한다. [예제] 디스플레이의 TIME 모드와 DATE 모드의 상태 전이 테스트 케이스를 아래와 같이 설계할 수 있다.

● 결정 테이블 테스팅(Decision Table Testing) 요구사항의 논리와 발생 조건에 따라서 생성될 수 있는 결과를 테이블의 형태로 나열한 것으로, 조건과 행동의 모든 가능한 조합을 고려하여 테스트 케이스를 생성하는 기법이다. [예제] 모든 사람은 350의 공제를 받는다. 단, 근무 이력이 있고, 나이가 40세를 초과하면 추가로 100의 공제를 받는다. 또한 앞의 조건과 상관없이 자녀가 4명이라면 50의 추가 공제를 받는다. 각 공제 조건에 따른 결과를 테이블 형태로 나열할 수 있다.

● 원인-결과 분석(Cause-Effect Graphing) 논리적으로 테스트 케이스를 생성하기 위해, 원인과 결과에 근거하여 테스트 케이스를 생성하는 방법으로, 시스템의 외부 동작만을 고려한다. 원인은 시스템의 내부 변화의 입력 상태를 나타내고, 결과는 시스템의 변환 또는 원인의 조합으로 인한 출력 상태를 나타낸다. [예제] 원인과 결과에 대한 표기법을 아래와 같이 나타낼 수 있다

● 조합 테스트 기법(Combinatorial Test Techniques) 잠재적 조합 요소의 거대한 양을 처리하기 위한 테스트케이스를 선정하는데, 도움을 주는 통계적 테스트 기법이다. 요구되는 테스트 케이스의 이상적인 개수를 계산하고, 입력 값과 조건의 차를 식별하여, 테스트 케이스 선정 프로세스에서 최대 커버리지를 가지는 최소 개수의 테스트 케이스를 제공하는데 도움을 준다. [예제] 파랑, 노랑, 빨강을 가질 수 있는 3개의 입력 값이 있을 경우, 조합 테스트 기법을 이용하여 다음 표와 같이 3³즉, 27개의 테스트 조합을 만들 수 있다

● 시나리오 테스팅(Scenario Testing) 비즈니스 시나리오 또는 프로세스 흐름을 기반으로 테스트 케이스를 설계하는 방법 이다. 시스템을 실제로 사용할 때 존재할 수 있는 결함을 발견하는데 유용하기 때문에, 인수 테스트를 설계하는데 유용하다. [예제] 쇼핑몰 시스템의 경우 아래와 같은 다이어그램으로 나타낼 수 있다

다이어그램 안에 있는 상품 구입, 상품 등록, 재고 확인, 구입 취소, 취소 확인 시나리오에 대하여 Actor(회원/관리자)와 시스템의 교환을 스토리로 기술한다.

● 오류 추정(Error Guessing) Ad-hoc Testing이라고도 불리며, 특정한 소프트웨어가 주어졌을 때, 직관과 경험의 의하여 어떤 특정한 형태의 결함이 발생할 것이라고 예측하고, 이 결함을 드러내 주는 테스트 케이스를 설계하는 기법이다. 직관적인 프로세스이기 때문에 특정한 프로시저를 가지는 것이 어렵다. 결함이 발생할 수 있는 상황들을 리스트로 열거해보고, 이 리스트를 테스트 케이스로 활용한다. [예제] 정렬 프로그램에서 에러가 발생하기 쉬운 경우는 아래와 같으며, 해당 상황을 고려하여 테스트 케이스를 선정할 수 있다. ⑴ 입력 리스트가 공란 리스트인 경우 ⑵ 입력 리스트가 하나의 원소만을 갖는 경우 ⑶ 입력 리스트의 모든 원소가 같은 값을 가지는 경우 ⑷ 입력 리스트가 이미 정렬되어 있는 경우

● 구문 테스팅(Statement Testing) 프로그램 내의 모든 문장들을 한번 이상 수행하도록 테스트 케이스를 설계하는 기법이다. [예제] 다음과 같은 제어 흐름도를 커버하는 구문 테스팅 테스트 케이스를 설계하기 위해서는 제어 흐름도의 모든 문장들을 통과하는 1개의 테스트 케이스가 필요하다

● 결정 테스팅(Decision Testing) 프로그램 내의 각 분기들을 한번 이상 수행하도록 테스트 케이스를 설계하는 기법이다. [예제] 다음과 같은 제어 흐름도를 커버하는 결정 테스팅 테스트 케이스를 설계하기 위해서는 제어 흐름도의 모든 분기들을 통과하는 2개의 테스트 케이스가 필요하다

● 조건 테스팅(Condition Testing) 프로그램 내의 각 조건들을 보장하기 위해 조건들이 참이 되는 경우와 거짓이 되는 경우를 모두 수행하도록 테스트 케이스를 설계하는 기법이다. [예제] 다음과 같은 조건을 커버하는 조건 테스팅 테스트 케이스를 설계하기 위해서는 3개의 테스트 케이스가 필요하다. if(A>1 AND B<=0){ A=B+4; }

● 데이터 흐름 테스팅(Data Flow Testing) 프로그램 내에서 변수들이 값을 할당 받은 지점이나 사용된 지점에 따라, 프로그램의 테스트 경로들을 선택하는 방법이다

유지보수

소프트웨어 유지보수 가. 정의
소프트웨어 개발 및 인수 후에 소프트웨어 오류수정, 사용자 요구사항 반영, 기능개선 등을 목적으로 하는 소프트웨어 수명 연장을 위한 핵심 공정 나. 종류

형태 설 명 특 징 수정적 유지보수 - Corrective Maintenance - 프로그램 오류로 인한 SW 오류수정 - 테스트 단계에서 발견되지 않은 오류를 고치는 유지보수 - 유지보수 도중에 오류가 유입되어 고치는 유지보수 하자유지보수, 처리오류, 수행오류, 구현오류 적응적 유지보수 - Adaptive Maintenance - 프로그램 환경변화에 S/W의 적응 - 소프트웨어가 운영되는 환경의 변화에 의하여 요구되는 변경 - 새로운 프로세서, 새로운 운영체제, 새로운 주변장치, 새로운 통신 프로토콜에 맞도록 소프트웨어가 변경될 필요가 있을 필요한 유지보수 이식개념, H/W or S/W 변화 완전적 유지보수 - Perfective Maintenance - 프로그램 특성 변경, 첨가 및 장래 유지보수성 향상 - 시스템에 새로운 기능을 추가하는 형태의 유지보수 - 개발하는 동안 미처 생각하지 못했던 기능을 추가하거나, 기존의 성능을 더 좋게 변경하거나, 사용자 인터페이스를 향상키거나, 성능을 개선하는 유지보수 수행력 향상 예방 유지보수 - Preventive Maintenance - 프로그램의 예측되는 오류를 선점 처리 - 유지보수성(maintainability)이나 신뢰성(reliability)을 향상시키기 위한 유지보수 프로그램의 예상되는 기능, 오류에 대해 발생 전 수정

다. 목적

목적 내용 성능개선 소프트웨어의 완전성, 편리성 하자보수 소프트웨어에 대한 오류, 결함 수정 신 환경 적응 환경변화 등에 대처하는 예방활동 품질특성 소프트웨어가 제공해야 할 품질 특성 만족

라. 중요성

분류 내용 관리적 S/W기능의 복잡화에 따라 문서화 등의 관리업무 증가 기술적 유지보수 운영비용이 전체비용의 70~80% 차지 운영적 S/W 신규 인력이 기술적으로 중요한 신규프로젝트보다 유지보수에 투입되는 낭비요소 발생

S/W 변화관리와 유지보수의 핵심인 Lehman 변화 원리 이해 가. Lehman S/W 변화 원리의 개념
S/W는 요구에 의해 계속적으로 변경되며, 변경에 따른 복잡성, 프로그램의 고유한 변경추세, S/W조직 생산성의 일관성, S/W 각 버전의 변화에 대한 일관성을 제시한 S/W 변화의 원리 나. Lehnam의 S/W 변화 원리의 중요성
S/W 변화의 특성을 이해하고 유지보수, 변경관리, 형상관리, 품질통제의 중요 모델로 반영
S/W변화의 특성을 S/W조직, 프로세스, 기술에 반영하여 Baseline 유지, CCB구성, 인력고도화, 버전관리등을 설계 다. Lehman의 S/W 변화 원리

구분 세부내용 계속적 변경 (Continuing change) 소프트웨어는 진화하며 요구사항에 의해 계속적으로 변경됨 복잡도 증가 (Increasing complexity) 변경이 가해질수록 구조는 복잡해짐 대규모 프로그램 진화 (Program evolution) 프로그램 별로 변경되는 고유한 추세가 있음 조직의 안정화 (Organizational Stability) 개발생산성이 변화에 민감하지 않고 안정됨 친근성의 유지 (Conservation of familiarity) 소프트웨어 각 버전의 변화는 일정함

Baseline을 기반으로 안정성 추구, 성능개선, 리팩토링 등을 통한 만족도 향상 라. Lehman S/W 변화의 원리 고려사항
유지보수는 Baseline을 기반으로 안정성을 추구하나 성능개선, 예방유지보수, 리팩토링 활동을 수행하여 안정성과 더불어 효과성, 사용자 만족성을 높이는 활동을 병행해야 한다
Increasing Complexity의 원리에 따라 변경을 수행한 후 Regression Test를 수행하여 Unit, Input, Partition, Path, DataFlow에 대한 검증을 통해 복잡성 증가에 대한 품질보증활동 수행 요구
유지보수 작업 단계

단계 내용 소프트웨어의 이해 프로그램의 구조 파악 및 프로그램 안에 사용된 변수나 자료구조의 의미를 파악 모듈이 어떤기능을 하는지 파악 주석 및 모듈 호출 그래프(module call graph), 참조표(reference table) 등을 만들어 요소관계들 파악 변경 요구 분석 변경이 불가피한 이유와 요구를 분석하여 이해 오류에 의한 것이라면 어떤 부분이 잘못되는지 추적 개작인 경우에는 새로운 환경을 철저히 연구하고 조사 기능향상을 위한 변경은 새로운 기능의 요구를 정확히 분석 변경 및 효과 예측 실제 변경이 일어나기 전에 변경으로 인한 이상효과(change effect)를 점검 코드 수정으로 인하여 영향을 받아 다른 부분을 고쳐야 하는지 점검 변경으로 인하여 영향을 받는 문서는 무엇이며 어떤 부분인지 확인 리그레이션 테스트 (regression test) 소프트웨어를 변경한 후에도 여전히 같은 기능을 하고 있음을 확인하기 위한 테스트 변경에 의하여 영향을 받는 부분만 다시 테스트

소프트웨어 개발과 유지보수 비용의 비교
소프트웨어 개발 : 코딩 중심의 작업
유지보수 : 이해 중심의 작업
개발 비용 : 분석, 설계에서 서서히 올라가다가 구현 단계에 최고점에 달하고 테스팅 이후 다시 낮아짐
유지보수 비용 : 이해 단계에서(분석, 설계) 많이 비용이 들고 실제 코드를 수정한 단계(구현)에서는 아주 적게 들며 적은 비용으로 테스팅 가능
효율적인 유지보수를 위한 3R 가. S/W 3R의 정의
완성된 소프트웨어 실체를 기반으로 역공학(Reverse Engineering), 재공학(Re-engineering), 재사용(Re-use)을 통해 소프트웨어 생산성을 극대화하는 기법
Repository(소프트웨어 저장소) 기반 나. S/W 3R의 필요성
소프트웨어 유지보수(CASE 도구 사용) 효율성 제고 및 비용 절감
소프트웨어 개발 생산성 향상
소프트웨어 이해, 변경, 테스트 용이
소프트웨어 변경 요구사항에 대한 신속한 대처 가능
소프트웨어 위기(소프트웨어 개발의 대형화, 복잡화, Life-Cycle 감소) 극복 다. 소프트웨어 3R의 개념도
역공학 : 구현된 것을 분석하여 설계단계로 요구사항 분석
재공학 : 역공학으로 재구조화된 S/W를 기반으로 다시 추상개념을 현실화하는 것
재사용 : 재공학을 통해 현실화된 S/W를 실제 사용
재구조화 : 기능 변경 없이 소스코드의 재편성(표현의 변형)
소프트웨어 개발 프로세스 단계를 거쳐가며 생산된 산출물과 원시 소스코드를 이용하여 역공학, 재공학, 재사용을 수행하여 소프트웨어 개발 생산성 향상 및 유지보수 효율성 제고
순공학 : 분석, 설계, 구현의 단계처럼 순차적으로 소프트웨어를 개발하는 것 라. 재구조화(restructuring)
소프트웨어가 전반적으로 잘 동작하고 있어 기본 아키텍처는 수정할 필요가 없음
프로그램의 질을 높이기 위해 보다 나은 문서화, 낮은 복잡도 향상
생산성이 향상되도록 특정한 부문의 모듈이나 데이터를 수정 마. 재공학(reengineering) 1) 정의
소프트웨어 역공학 및 재구조화 등의 기술을 이용하여 소프트웨어를 분석하여 정보를 추출하고, 이를 다시 순공학을 사용하여 새로 구현함으로써 재사용성을 확보하는 소프트웨어 부품으로 만들어 내는 기술 작업 2) 방법

분류 내용 재구조화 시스템의 외부행위(기능+의미론적) 유지, 동일한 추상화 표현 상태를 다른 표현 형태로 변환하는 과정 재모듈화 모듈구조 변화(시스템 구성요소의 클러스터 분석 등), 결합도와 관련됨 의미론적 정보 추출 코드 수준이 아닌 문서 수준의 설계 복구 방법임

3) 목적 - 현재 시스템의 유지보수 향상, 표준의 준수 및 CASE 사용용이 - 시스템의 이해와 변형을 용이하게 하며, 유지보수 비용 및 시간 절감 4) 필요성(장점) - 유지보수 비용이 많이 드는 경우 - 시스템 이해와 변경 및 테스트가 어려운 경우 - 시스템 문제 증가 및 통합 작업에 잦은 장애 발생 할 경우 5) 장점 - CASE 사용이 용이하여 현재 시스템의 유지보수 향상 - 표준을 준수하여 시스템 이해와 변형을 용이하게 하며, 유지보수 비용 및 시간 절감 6) 단계(절차)

절차 내용 레거시 분석 - 애플리케이션 인벤토리 - 영향도분석 - 애플리케이션 관계 - 소스변화 관리 역공학 - 파싱 - 비즈니스 로직 마이닝 - 후보 컴퍼넌트 - UI 재구성 코드 재구성 - 컴퍼넌트 재구성 - 컴퍼넌트 재사용 - 소스코드 편집 데이터 재구성 - 데이터베이스 재 모델링 - 필드 속성 관리 - 스키마 코드 자동 생성 순공학 - 컴퍼넌트 설계 - 컴퍼넌트 빌드 - 컴퍼넌트 관리(리포지토리)

7) 재공학의 기술 (1) 리엔지니어링 기술의 접근 방법 - 역공학 도구 : 코드에서 원하는 정보를 추출하는 기법 - 노후시스템의 설계 사양을 복원 - 변경이 힘든 경우 새로운 시스템의 부분요소로 캡슐화가 가능 (2) 리엔지니어링 기술의 특성 - 논리적 모델링 - 슬라이싱 (3) 비용절감 효과에 대한 예측 (4) 데이터베이스 리엔지니어링 - 데이터베이스 패러다임의 변화, 서로 다른 데이터베이스 시스템 간의 마이그레이션 등의 개발 (5) 사용자 인터페이스 리엔지니어링 - 그래픽 중심의 사용자 인터페이스로의 변환 (6) 분산 시스템으로의 리엔지니어링 - 메인프레임에서 분산 클라이언트/서버 시스템으로의 전환 (7) 객체지향 시스템으로의 리엔지니어링 - 절차중심의 노후 시스템을 객체지향시스템으로의 변환 마. 역공학(Reverse Engineering) 1) 정의 - 기존 개발된 시스템 CASE를 이용하여 사양서, 설계서 등의 문서로 자동 추출하는 작업 - 개발 단계를 역으로 거슬러 올라가 기존 개발된 시스템의 코드나 데이터로부터 설계 명세서나 요구 분석서 등을 도출해 내는 작업 - 소스코드 없이 윈도우즈 실행 파일(PE, Portable Executable)이나, 자바 바이트코드 등을 직접 분석해서 프로그램이 어떤기능을 수행하는지 파악하여 취약점을 찾아내는 기술 - 바이너리 코드를 분석해 유용한 정보를 뽑아내는 작업 - 현실의 추상화 2) 역공학의 개념

디컴파일러(decompiler) => 컴파일된 바이너리를 다시 원래의 소스코드로 복구하는 프로그램 => 원래 소스코드를 완벽히 복구하지는 못하지만, 어셈블리에 비해서는 훨씬 이해하기 쉬운 프로그래밍 언어(주로 C)의 소스코드를 생성 2) 종류

분류 내용 논리 역공학 소스코드 분석 추출 설계정보 추출 자료 역공학 기존 DB분석 및 설계정보 추출 DB구조개선 및 마이그레이션에 활용

3) 필요성(장점) - 현존 시스템의 유지보수성 저하 - 변경이 빈번하여 시스템 효율성 저하 - 시스템 마이그레이션 및 다운사이징 4) 입력 및 출력

입력 출력 소스코드, 목적코드, 작업제어절차 구조도 텍스트 자료, DB구조 자료사전, 자료흐름도, 자료흐름그래프 I/O형태 및 자료, 각종 Document 제어흐름 그래프, 개체관계도(ERD)

바. 3R의 구성요소

구분 설명 역공학 (Reverse Engineering) 자동화된 도구(CASE)의 도움으로 기존 시스템에서 사양서/설계서 등의 분석 및 설계에 관한문서를 추출하는 작업 문서를 남기지 않은 소스코드를 유지보수하기 위하여 여러가지 정보를 회복시키는 기술 재공학(Re-engineering) 역공학으로 재구조화된 SW를 기반으로 추상 개념을 다시 현실화하는 작업 재사용(Reuse) 재공학을 통해 현실화된 SW의 사용

사. 목적 - SW개발 생산성 향상 및 표준화(언어, 아키텍처, 명명규칙) - 유지보수성 향상 및 SW 수명 연장 - 시스템 이해 및 변경 - 테스트 용이성 향상 6. 코드 난독화(code obfuscation) 가. 코드 난독화(code obfuscation)의 정의 - 프로그램을 변화하는 방법의 일종으로, 코드를 읽기 어렵게 만들어 역공학을 통한 공격을 막는 기술 나. 코드 난독화 필요성

필요성 설명 소스코드를 릴리즈 (release) 플래시 파일 시스템을 파는 A라는 회사가 있다고 하자. B 회사는 A 회사의 라이브러리를 구매해서 제품을 만들려고 한다. B 회사는 매우 많은 플랫폼을 가지고 있고, 여러 설정에 따라서 플래시 파일 시스템을 조금씩 다르게 컴파일해야할 필요가 있다고 하자. 이 경우 B 사가 일일이 해당 라이브러리를 빌드해서 릴리즈해주는 방법도 있지만, 난독화 도구를 이용해 코드를 적당히 알아보기 힘들게 만든 후에 A 사에 넘겨서 A사가 직접 빌드하도록 하는 것이 편리할 것이다. AJAX 자바스크립트(JavaScript)로 작성된 코드가 브라우저에 그대로 노출되는 문제가 있다. 소스코드를 공개하고 싶지 않은 개발자라면 AJAX의 이런 특성이 큰 부담이 될 것이다. 이 경우 자바스크립트 코드를 쉽게 알아보지 못하도록 난독화 도구를 사용할 수 있다

나. 코드 난독화 종류

종류 설명 소스코드 난독화 C/C++/자바 등의 프로그램의 소스코드를 알아보기 힘든 형태로 바꾸는 기술 바이너리 난독화 컴파일 후에 생성된 바이너리를 역공학을 통해 분석하기 힘들게 변조하는 기술

다. 바이너리 코드 난독화 방법 1) 바이너리에서 심볼 정보를 제거하거나 변경

방법

C/C++ C/C++로 컴파일된 바이너리의 경우 디버깅 옵션을 주면 바이너리에 심볼 정보가 포함되는데 난독화 도구는 이런 정보를 지워서, 바이너리에서 사람이 이해할 수 있는 정보를 최대한 제거 Java 심볼 정보가 프로그램 수행에 필요하므로, 심볼 정보를 제거할 수 없음 자바용 난독화 도구는 심볼 이름을 바꾸는 방법을 많이 사용 MyString이라는 클래스 이름보다는 M라는 클래스 이름이 알아보기 어렵고, find라는 메쏘드 이름보다는 f라는 이름이 공격자가 이해하기 어렵다는 점에 착안

2) 필요 이상으로 복잡한 코드를 만들거나, 아무것도 하지 않는 코드를 삽입 - 실행되지 않는 함수를 추가하거나, 아무것도 하지 않는 함수들을 중간 중간에 삽입하여 바이너리 코드 분석을 힘들게 만듬 - 공격자가 함수 호출 그래프(call graph)와 흐름 그래프(control flow graph)를 그리고, 세심하게 코드를 분석하면 취약점을 찾아내는 것은 시간문제 3) 코드를 여기저기로 복사하고, 옮김 - 코드를 최대한 멀리 떨어진 곳에 배치하거나, 함수를 인라이닝(inlining)하고, 반복되는 몇 개의 구문(statement)을 합쳐서 익명의 함수를 만듬 - 똑같은 함수를 복사하여, 각기 다른 지점에서 다른 함수 이름을 사용하는 방법 - 서로 관련 없는 함수를 하나의 함수로 묶어주는 방법 4) 데이터를 알아보기 힘들게 인코딩(encoding) - 텍스트 문자열을 알아보기 힘든 방식으로 인코딩하고 필요할 경우만 디코딩(decoding)해서 사용하는 방법 7. 유지보수에 대한 접근 방법

S/W 유지보수 문제점 및 발전전망 가. S/W 유지보수 문제점
소프트웨어에 대한 변경이 수시로 일어나며 이를 문서에 반영하지 않는 경우 이를 추적하는 것은 거의 불가능
다른 사람이 작성한 프로그램을 이해하는 일은 쉽지 않으며 문서화되어 있지 않거나 주석도 달지 않았다면 문제는 매우 심각
소프트웨어 변경을 가정하여 설계되는 경우가 드믐(모듈의 기능을 독립시키고, 정보를 은닉하여 변경에 충분히 대비하여 설계)
유지보수를 위한 적극적인 도구를 사용하지 못함(프로그램 이해를 위하여 테스트나 디버깅 도구를 사용하는데만 그침) 나. S/W 유지보수의 발전방향

관점 발전전망 표준화 변경관리, 분석활동, 기본설계, 상세설계, 구현활동과 같은 개발활동을 현 시스템에 맞춰 표준화 시행 자동화 재공학 도구의 발전으로 유지보수 자동화 지원 활동이 강화될 전망 전략 S/W 패키지화 및 효율적인 형상관리 기법을 도입하여 유지보수 향상을 위해 전략적으로 노력해야 함

소프트웨어 유지보수 생산성을 향상하는 방법 가. 소프트웨어 개발 단계에 미리 예방적 조치를 취하는 방법 나. 유지보수 활동과 관련된 여러가지 도구를 동원하여 생산성을 높이는 방법
소프트웨어 유지보수 방법 가. 예방차원의 기술(유지보수성 향상 기술) 1) 시스템 설계 단계
명확성, 모듈성, 변경 용이성을 강조하여 설계 기준을 정함
ex : 수행속도 및 기억장소의 최소화와 같은 다른 설계 기준보다 변경이 쉽도록 명확성, 모듈성을 강조 2) 구현 단계
간단하고 명료한 코딩 스타일 유지
상수의 사용을 기호화하여 추후 변경이 용이하게 하고 자료를 캡슐화하여 변경에 노출시키지 않음
자료구조의 크기를 충분히 잡아 환경이 변화에 의한 유지보수 대비
각 모듈의 헤더와 주석을 달때 일관된 방법으로 자세히 설명 3) 유지보수 지침서, 테스트 사례집(test suite)
유지보수 지침서 : 전체 시스템의 동작 및 기능에 대한 기술적인 설명과 시스템의 구조도, 호출 그래프, 앞뒤 참조표(cross reference table) 포함
테스트 사례집 : 시스템의 통합 테스팅 및 고객의 인수 테스팅에서 사용된 테스트 사례와 결과들을 관리
리그레이션 테스팅 : 소프트웨어 변경시 테스트 사례집을 이용하여 필요한 부분만 리그레이션 테스팅 나. 프로그램 이해 기술 1) 프로그램 이해 방법
상향식 방법 => 시스템의 전체 기능을 서브 기능으로 이해하는 방법 => 프로그램을 구성하는 각 함수와 프로시저의 소스코드를 보고 어떤기능을 하고 있는지 분석
하향식 방법 => 서브 기능의 이해는 무시하고 시스템 전체의 모습을 먼저 이해하고 아래 단계로 내려가는 방법 => 소스코드를 추적하면서 시스템에서 어떤 블록이 어디서 호출되었는지 분석 2) 프로그램 이해 단계
프로그램의 구조를 따라 훑어보고 의미 있는 이름을 찾음
프로그램안에 사용되는 개체들(상수, 타입, 변수, 프로시저 기능)을 찾음
소스코드를 위에서 아래로 분석(반복이나 선택 구조의 의미를 파악)
프로그램 논리를 순서대로 따라가며 파악 다. 유지보수 단계의 테스팅
리그레이션 테스팅 수행(변경된 프로그램을 이전에 수행한 테스트 케이스로 실행함으로써 변경 후에도 제대로 작동하는지 확인)
리그레이션 오류(regression fault) : 관계없는 부분에 영향을 주는 수정 라. 역공학 기술 1) 정의 : 소스코드로부터 다양한 정보를 만들어 내는 기술 2) 소스코드가 있는 경우
소스코드에서 논리 흐름도나 NS도표, 시스템 구조도 추출 및 자료 흐름도 작성
낮은 추상도를 가진 표현에서 높은 추상도의 표현을 추출하는 작업 3) 소스코드가 없는 경우
실행 프로그램을 디어셈블(diassemble)하여 어셈블리 언어로 표현된 형태로 바꿈
시스템을 블랙박스로 보고 명세서를 유추하여 복원하는 작업
소프트웨어 유지보수 도구 가. 기술지원 도구 1) 소스코드를 분석하여 프로그램의 이해에 도움을 주는 도구

분류 종류 내용 정적분석 도구 앞뒤 참조표 (cross reference table) 프로시저의 호출, 변수 선언, 변수 사용에 대한 색인표 호출 그래프 (call graph) 각 모듈의 호출 관계 및 호출 프로시저 이름, 매개변수를 보여줌 자료 흐름도 (data flow chart) 변수의 선언과 사용의 관계를 그래프로 나타내어 변수값의 변동 추이를 알려줌 시스템 구조도 (system structure chart) 소스코드에서 설계 문서인 시스템 구조도를 자동으로 추출(역공학) 동적분석 도구 디버깅 도구 (debugging) 트랩(trap), 덤프(dump), 트레이스(trace), 가설점검(assertion checking) 동적분석기 소스코드 중간에 원하는 성질을 점검하는 코드를 삽입하여 프로그램을 실행하는 방법

2) 변경에 의한 영향을 분석하는 도구 3) 변경 후 테스팅에 필요한 도구 - 소스코드에서 어떤 변수의 선언을 변경하였을 경우 영향을 받는 모든 변수의 사용 부분을 점검 - 텍스트 편집기의 찾기 기능을 사용 - 비교기(comparator) 사용 : 버전간의 차이점을 지적하고 부작용이 변경에 의해 일어나는지 판단 4) 복잡도, 신뢰도 등 프로그램의 특성을 측정하는 도구 나. 관리지원 도구 1) 버전관리 도구 2) 형상관리 도구

소프트웨어 재사용을 위한 2가지 분류 방식 1. Enumerative 분류 방식 (Top-Down 방식) 가. 정의 - 일반적인 지식을 점차 좁은 클래스로 분할 하면서 그들간의 관계를 표현하는 방식 - 가능한 모든 클래스를 계층적으로 미리 정의한 다음, 각 부품들을 가장 알맞은 클래스에 할당하는 방식 나. 장점 - 객체들이 갖는 여러 가지 속성들을 한꺼번에 고려하여 분류 체계에 표현하여 클래스간 계층적 관계가 자연스러움 다. 단점 - 분류체계가 크고 복잡하면 이해하기 어려움 - 확장이 어려움 - 미리 모든 클래스를 정의해 두어야 함 라. 예 - 생물 : 식물, 동물 - 동물 : 육상동물, 수상동물 2. Facet 분류 방식 (Bottom-up 방식) 가. 정의 - 적당한 항목들을 선택하여 이들을 합성(synthesis)함으로써 객체를 분류하는 방식 - 객체들이 갖는 기본적인 클래스만을 표현하는 방식 나. 장점 - 분류체계가 간단하여 이해하기가 쉽고 - 해당 facet에 기본적인 클래스만 첨가하여 분류체계를 확장시킬 수 있어 확장이 용이 다. 단점 - 클래스간의 계층성을 명시적으로 분류 체계에 표현하기 어려움 라. 예 - 생물 facet : 식물, 동물 - 서식지 facet : 수상, 육상 - 계통 facet : 무척추, 척추 ★ 컴포넌트에서 facet 분류 방식을 사용하는 이유 1) Enumerative 분류 안은 Facet 분류안보다 컴포넌트 상호간의 계층적인 관계를 잘 나타내지만, 전혀 성질이 다른 새로운 컴포넌트의 추가시에는 사용자의 요구에 따라 분류 계층을 다시 작성해야 함. 즉 신축성이 떨어짐 2) Facet 분류안은 계층적 의미가 아니라 수평적인 의미이므로, 한 개의 새로운 컴포넌트의 추가에도 쉽게 추가/삭제가 용이하기 때문에 facet 분류 방법 사용

형상관리(configuration management, 구성관리라는 용어로도 사용되기도 함) 가. 정의
소프트웨어에 가해지는 변경을 제어하고 관리하는 것
변경에 대한 보호 활동이며 변경의 원인을 알아내고 변경을 제어하며 적절히 변경되고 있는지 확인하고 변경에 관심을 가지고 있는 사람들에게 통보하는 작업
개발 후에 일어나는 소프트웨어에 대한 관리
성공적인 형상관리는 소프트웨어를 개발 전, 개발 중에 계획하여야 함 나. 형상관리 대상
유지보수 : 문서(기능 명세, 설계 명세, 테스트 슈트)와 목적코드, 소스코드
계획 : 프로젝트 계획, 분석서, 설계서, 프로그램, 테스트 케이스 다. 형상관리 필요성

문제원인 내용 가시성의 결핍 소프트웨어는 무형임 통제의 어려움 눈에 보이지 않는 소프트웨어 개발에 대한 통제가 현실적으로 어려움 추적의 결여 소프트웨어 개발 과정에 대한 추적의 어려움 감시의 미비 가시성 결핍 및 추적의 어려움으로 프로젝트 관리를 지속적으로 감시하기 어려움 무절제한 변경 무절제한 사용자의 요구사항 변화에 의한 형상물 변경 발생

형상관리 관리적인 측면 및 기술적인 측면 가. 형상관리 관리적인 측면 1) 형상관리 위원회(형상관리 팀)

구성원 내용 분석가 사용자와 상의하여 무엇이 문제이며 어떤기능 향상 및 개작이 필요한가를 분석 프로그래머 분석가와 협동하여 문제의 원인을 찾아내고 변경의 형태와 내용을 알아냄 실제 프로그램의 수정을 담당 프로그램 사서 문서와 코드에 대한 변경을 계속 보관하고 관리

2) 변경 요청서(change request) - 소프트웨어의 변경을 원하는 사용자나 프로그래머 등에 의하여 작성되는 양식 - 사용자가 오류를 발견하였거나 기능 향상을 원하는 경우 작성 3) 변경 제어 절차

나. 형상관리 기술적인 측면 1) 어떤 방법으로 시스템에 관련된 모든 변경을 추적하여 현재 상태를 항상 알 수 있도록 관리 2) 형상관리 항목(configuration item) - 요구분석서, 시스템 명세서, 운영 및 설치 지침서, 유지보수 문서, 소스코드 목록 3) 버전 제어 라이브러리 - 소프트웨어 제품의 여러 버전을 이루는 파일 추적하고 제어 4) 델타(delta) 파일 - 프로그램 버전 차이 - 장점 : 작은 장소에 많은 버전 보관 가능 - 단점 : 원래 프로그램 파일에 이상이 있다면 다른 버전에 파급 효과가 큼

I. S/W에 대한 체계적인 관리, 가시성 확보 및 제어 활동, S/W 형상관리의 개요 가. S/W 형상관리(Software Configuration Management)의 정의 - S/W 생명주기 및 유지보수 과정에서 만들어지는 각 단계별 산출물을 체계적으로 관리하여 S/W 품질보증활동을 향상시키는 기법 - S/W SDLC 단계의 산출물을 체계적으로 관리하여 S/W 가시성 및 추적성을 부여하여 품질보증을 향상시키는 기법 - S/W를 이루는 부품의 Baseline(변경통제 시점)을 정하고 변경을 철저히 관리 통제하는 활동 - S/W 형상항목을 식별하여 체계적으로 형상의 변경을 통제하고, SDLC 전반에 형상의 추적성과 통합성을 유지하여 형상물의 정합성을 보장하는 활동 나. S/W 형상관리의 필요성 - S/W 개발 통제의 어려움 - S/W 추적의 결여 및 무절제한 변경 - S/W 가시성(Visibility)의 결핍 다. 형상관리의 역할 - 이전 리버전이나 버전에 대한 정보에 언제든지 접근 가능 - 불필요한 사용자의 소스 수정 제한 - 동일한 프로젝트에 대해 여러개발자 동시 개발 가능 - 에러가 발생했을 경우 빠른 시간내에 복구 가능 - 사용자의 요구에 따라 적시에 최상의 소프트웨어 공급 라. 형상관리의 목표(암기: 식통감기)

II. 형상관리의 개념도 및 구성요소 가. 형상관리의 개념도

S/W 형상항목을 식별하여 위원회를 통하여 체계적으로 형상의 변경을 통제하고, 그 기록을 저장하여 형상물의 정합성을 보장 나. 형상관리의 구성요소

구성요소 내용 기준선 (Baseline) - 각 형상 항목들의 기술적 통제시점 - 모든 변화를 통제하는 시점의 기준 형상항목 (Configuration item) - 프로젝트에서 공식적으로 정의되어 관리되는 모든 대상 - 문서, 프로그램, 데이터 등 형상물 (Configuration product) - 형상관리의 실제 대상 콘텐츠로 기술문서, H/W 제품, S/W 제품 등 - 기술 문서 : 분석/설계 관련 산출물, 각종 매뉴얼 등 - 개발 TOOL : 컴파일러, 링커, 함수/라이브러리 등 - Source Code : Source Module, JCL, Compile Option, Object Module, Load Module, 실행파일 형상버전 (Configuration Version) - 기준선을 설정한 후 일어난 변경기록. 변경허가에 의해 변경시 버전 갱신 - 식별명과 버전으로 시스템 구성요소를 하나로 식별함 CCB (Configuration Control Board) - 형상관리 위원회는 소프트웨어 베이스라인에 대한 설정의 권한과 이에 대한 관리 기능을 갖는 조직 - PM과 더불어 SDLC 단계에 따른 개발 산출물의 베이스라인 관리 및 통제 Repository - 형상관리 항목들에 대한 물리적 저장공간 및 형상 메타 데이터의 저장공간

III. 형상관리의 절차 및 단계별 기준선 가. 형상관리 절차(형상관리 관리 기법)

단계 내용 형상식별 - 형상관리 대상 구분, 관리목록에 대한 번호 부여 - 형상 식별기능의 목표 : 문서구조를 명료하고 예측 가능한 모습으로 정의 : 정보기록에 의해 추적 관리를 용이하게 함 - 형상 식별 내용 : 제품/각종문서 항목번호 형상통제

S/W 형상 변경 제안을 검토 승인하여 현재 S/W Baseline에 반영할 수 있도록 통제
변경 요구관리/변경제어/형상관리 조직의 운영 및 개발업체 외주업체에 대한 형상통제 지원 형상감사
S/W Baseline의 무결성 평가수단
성공적인 형상감사는 S/W Baseline을 성공적으로 설정
기준선 변경시 요구사항과 일치 여부 검토
검증(Verification) 및 확인(Validation) 형상기록
S/W 형상 및 변경관리에 대한 각종 수행결과를 기록
DB에 의한 관리를 하며 보고서를 작성하는 기능

나. 생명주기 단계별 기준선(SDLC별 형상관리 항목 참조) – 기분설시제운

단계 기준선 형상관리 항목 산출물 계획 기능적 기준선 (Function Baseline) 사용자 요구기능이 정의되는 시점 개발계획서, 형상관리계획서 요구분석 분배적 기준선 (Allocated Baseline) 요구기능이 서브시스템으로 분할되는 시점 요구사항정의서 설계 설계 기준선 (Design Baseline) 개발 전 설계사양이 완성 되는 시점 각종 설계서(ERD, DFD, Class Diagram) 구현 시험 기준선 (Test Baseline) 시험을 위한 준비수립 시점 원시/목적코드, 실행코드 시험 제품 기준선 (Product Baseline) 통합, 기능, 성능 등의 시험완료 시점 시험보고서 설치/운영 운영 기준선 (Operation Baseline) 개발이 완료되어 운영을 위해 이관되는 시점 사용자/운영자 매뉴얼

프로젝트 단계별 기준선은 Formal Technical Review에 의하여 승인 다. FTR(Formal Technical Review)=정형 기술 검토 1) 정형 기술 검토의 정의
프로젝트 산출물이 고객의 요구사항과 품질을 만족하는지 보장하는 품질보증 기법 ※ 정형 기술 검토는 제품의 오류를 식별하는 것이고 사람을 질책하는 것은 아님. 2) 정형 기술 검토(FTR)의 특징
요구사항 검토에서 인수테스트의 최종 검토까지 V-Model 모든 단계에서 수행되며, 개발 초기에 수행할수록 오류 비용은 감소함(Snowball Effect)
FTR을 수행 후 중대한 결함이 발생하면 이전 단계를 다시 수행하여 결함을 제거해야 함. 3) FTR의 목적
소프트웨어 표현을 위한 기능, 논리, 구현의 결함을 도출
소프트웨어가 요구사항과 일치하는지 검증
정의된 표준에 따라 표현되었는지를 보증
균일한 방식의 소프트웨어 개발 지원
프로젝트의 효과적 관리 지원
조기 결함 발견 및 예방을 통해 품질비용을 최소화하기 위함.
기능과 로직의 오류 발견(해결책을 제시하지는 않음)
4) 공식검토의 종류

구성요소 내용 Review - 부적절한 정보, 누락되거나 관련 없는 정보의 발견, 요구명세서와 일치성 검토 - 시스템개발요원, 관리자, 사용자, 외부전문가 참여 Inspection - 소프트웨어 구성요소들의 정확한 평가, Review보다 엄격, 정형화 됨, Check List등 사용 전문 지식을 가진 팀으로 구성 - 진행자의 진행 능력에 따라 Inspection 품질 좌우됨 - 계획 -> 사전교육 -> 준비 -> 인스펙션 회의 -> 수정 -> 후속조치 Walk-through - 비공식적인 검토과정으로서 개발에 참여한 팀들로 구성

IV. 개발 프로젝트와 운영 프로젝트의 형상관리 비교 가. 개발 산출물 측면

구분 개발 프로젝트 운영 프로젝트 목적 - 산출물의 가시성, 추적성, 무결성 확보 - 개발자 공동개발에 따른 버전관리(Source Code Control) - 운영환경 배포 후 장애 최소화 - 변경 소스 문제 발생 시 신속한 원상복구 주요 형상항목 요구사항 정의서, 설계서, 개발코드, 테스트 산출물 등 현 SW버전, 설계서, 사용자/운영자 지침서 등 변경요인 요구사항의 상세화, 수정, 추가, 삭제 등 요구사항 변경 위주 기능 개선 및 업무 프로세스 변경, 법/제도 변경, 내/외부 요인에 따른 변경 변경주체 개발자 유지보수 담당자 통제주체 형상통제위원회(CCB), SW아키텍트, 개발리더등 형상관리자, 품질관리자 등

나. 관리 프로세스 측면

구분 개발프로젝트 운영프로젝트 목적 - 개발자간 원활한 협업체계 구축을 통한 개발 생산성 향상 - 무절제한 변경 예방으로 Risk 최소화 변경에 따른 지속적인 산출물 현행화 통한 변경용이성 확보(담당자 변경등에 유연한 대처) -> 유지보수 비용절감 Focus 개발 Product 자체의 품질 향상 효율적인 ITSM 체계 구축을 통한 IT 서비스의 품질 향상 핵심 프로세스 변경관리 : FTR 후 결함 조치, 요구사항 변경 등에 따른 변경활동에 중점 - 서비스 데스크 : RFC, SR 관리 - 변경관리 : 변경영향도 평가(Risk 평가) - 배포관리 : 서비스 영속성을 보장하는 배포 정책(개발/테스트/운영 환경으로의 검증 및 이관) KSF - 개발 환경에 최적화된 관리도구의 활용 - 프로젝트 규모에 맞는 형상관리 정책 형상관리 SLA 지표를 반영하여 지속적인 관리 및 프로세스 개선

V. 형상항목의 라이프사이클 및 형상관리 조직 가. 형상항목의 상태변경에 따른 형상관리 라이프 사이클

나. 역할별 형상 변경 절차(소스/산출물)

다. 형상관리조직 1) 구성 : 개발담당/책임자, 형상관리자, 개발업체 PM/PL, 자문위원 2) 역할 : Baseline 승인 및 확정, 변경승인 및 변경 후 무결성 감사

구분 내용 분석가 - 사용자와 협의를 통한 문제점 도출, 기능향상 및 변경사항 결정 프로그래머 - 변경의 형태와 내용을 알아내고, 실제 프로그램을 수정 형상 담당자 - 문서와 코드에 대한 변경을 계속 보관, 관리 형상통제 위원회 - 형상항목에 대한 형상 기준선이 승인/설정된 후, 발생되는 형상항목의 변경에 대하여 평가, 조정, 승인/기각을 결정하는 심의 조직(CCB, Configuration Control Board)

VI. 형상관리에서의 소프트웨어 변경관리와 배포관리 가. 형상관리에서의 소프트웨어 변경관리와 배포관리의 관계도

변경관리는 변경의 영향도를 분석하고 승인하여 변경을 수행하며 배포관리에서는 직접적인 수정 및 배포를 수행 나. 소프트웨어 변경의 결정, 소프트웨어 변경관리(Software Change Management) 1) 소프트웨어 변경관리(Software Change Management)의 정의
서비스 품질에 근거한 사고(Incident)와 관련 있는 변경의 영향을 최소화하고, 조직의 일상적인 운영 개선을 위하여 모든 변경이 효율적이고 신속히 표준화된 방법과 절차가 사용되는 것을 보장하는 관리기법 2) 소프트웨어 변경관리의 절차

Activity 설명 변경요청 - 개발/현업/서비스관리 등의 부서에서 변경사항이 발생하면 해당자의 확인을 받은 변경요청서(RFC)를 통해 변경을 요청 변경결정 - 변경관리자는 변경요청서를 검토하여 변경의 적합성을 여과, 필요하지 않을 때는 변경 요청자에게 회송, 적합하다고 판단 시 변경 모델 결정 단순변경 - 변경관리자가 변경내용의 영향도가 적다고 판단될 시 가능 - 단순 변경 승인 및 구성관리 갱신 요청 및 구성관리에서 갱신 - 변경 수행 후 단순 변경 모델 종료 CAB/CCB 개최 - 변경의 영향도가 클 경우 변경의 긴급성을 판단하기 위해 개최 - CAB의 결정에 따라 긴급변경이나 일반 변경을 결정함 긴급변경 - 긴급 시험 실시, 성공 시 변경 요청, 긴급 변경 수행 - 긴급 변경이 정상적으로 수행 되면 일반 변경과 같은 수행 - 변경 후 사후 보고 및 사후 형상관리 감사 필요 - 긴급변경이 실패 할 경우 철회 계획을 수행하고 CAB에 송부, 철회 영향력 분석 및 철회에 따른 문제 관리 프로세스 진행 일반변경 - 변경수행 및 철회 계획수립, 변경사항 사전 시험 - 변경 조정 및 변경 수행 - 변경사항 구성관리 DB갱신 요청, 구성관리 프로세스, 변경사항 일정 기간 평가 - 일반변경이 실패할 경우 철회 계획을 수행하고 CAB에 송부, 철회 영향력 분석 및 철회에 따른 문제 관리 프로세스 진행

3) 소프트웨어 변경관리 시 고려사항 - 해당 형상물의 Ownership을 명확히 하여 변경에 대한 권한 및 방향을 결정해야 함 - 비즈니스의 연속성과 IT 연속성 계획의 연결 고리를 가지고 접근해야 함(수정으로 인해 비즈니스 루틴이 변경됨) - 언제까지 수행해야 하는 정확한 시간척도(Timescale)를 계산해서 변경의 종류를 정해야 함 - 변경에 대한 위험(Risks)을 사전에 인지하여 변경 의사결정에 사용해야 함 - 모든 변경은 복귀전략(Regression strategy)을 가지고 있어야 함 - 변경 요청/승인 등의 중요 의사결정에 대한 증거문서(Invocation)를 보관해야 함 다. 소프트웨어 변경을 사용자에게 전달하는 소프트웨어 배포관리(Software Release Management) 1) 소프트웨어 배포관리(Software Release Management)의 정의 - IT서비스상의 소프트웨어의 변경사항을 배포하고 설치하기 위한 효율적인 절차를 설계 및 구현하여 성공적인 버전별 설치를 계획/검토하며 롤아웃 기간 동안 고객의 기대를 이해하고 반영하는 관리 활동 2) 소프트웨어 배포관리의 절차

환경 Activity 설명 개발 환경 배포 정책수립 - 단계적 배포/일괄 배포 등 정책적 결정사항 수립 - 변경의 우선순위/위험도 정도에 따른 등급별 정책 사전 수립 - 조직의 시스템 아키텍처, SW관리 표준과의 일치 확인 배포 계획수립 - 사전 정책에 정의된 방침 대로 배포 일시, 릴리즈 방법/예산 등을 수립 - 릴리즈 실패 시에 실패 대응 계획수립 SW설계/개발 - 변경관리에서 분석된 영향도에 따라 소프트웨어의 전체 설계 변경 - 설계에 따른 개발 후 단위 테스트 완료 통제된 테스트 환경 릴리즈 구축 및 구성 - 실 환경과 비슷한 환경에서 전체 빌드 테스트 진행 - 소프트웨어의 변경에 따른 라이브러리/프레임워크 충돌 확인 릴리즈 목적 부합성 검사 - 변경 요청자 또는 조직의 요구사항이 정확히 반영되었는지의 확인 - 전사 프로세스 변경이 있는지 확인하고 있을경우 이해관계자와 확인 정상 버전 인수 - 변경사항이 모두 승인되었을 때 해당 버전를 완결하고 인수 - 데이터 이전의 정합성 테스트 까지 수행 필요 운영환경 롤 아웃 계획수립 - 이전버전에서 신규버전으로 변경에 따른 계획수립 - 변경시점(야간 등), 병행 운영 또는 빅뱅방식 등의 계획수립 의사소통 준비 및 훈련 - 각 이해 당사자에게 신규 시스템의 사용법 및 주의 사항을 사전 배포 - 롤 아웃에 대한 사전 모의훈련 및 진행 시간 확인 (특히 데이터 마이그레이션 시 주의) 배포 및 설치 - 서버 시스템의 경우 해당 시스템 바로 반영 후 모니터링 - 사용자 배포 필요할 경우 온/오프라인 배포 진행 확인

3) 소프트웨어 배포관리(Software Release Management)시 고려사항 - 조직의 시스템 아키텍처, 서비스 관리 및 기반구조 표준과의 일치하는 것을 확인 - 빌드, 설치, 핸들링, 포장 및 인도과정에서 무결성을 유지하는 것을 보장 - 빌드 및 릴리즈 프로세스 과정에서 컴포넌트를 관리하고 통제하기 위한 소프트웨어 라이브러리 및 관련 레파지토리 활용 - 리스크를 명확히 식별하여야 하며, 필요한 경우 교정 조치 - 타겟 플랫폼이 설치이전에 사전에 정한 요건을 충족하는가에 대한 검증 가능 여부 확인 - 릴리즈가 목표지점에 도착하는 시점에 그 완전성에 대한 검증 가능 여부 확인 VII. 형상관리위원회(Configuration Control Board) 체계적인 변경관리를 위한 필수 조직으로 각종 변경 요청에 대해 변경의 필요성 및 미치는 영향에 대한 분석을 수행한 후 승인 여부를 결정하는 조직 경험이 풍부한 숙련된 개발자 또는 파트리더로 구성

프로젝트 관리자 형상관리 계획서를 승인하고 형상관리가 적절히 수행될 수 있도록 지원/감독 형상관리 책임자 프로젝트 계획수립 시 해당 프로젝트의 형상관리 계획을 수립하고, 형상관리 활동이 적절히 수행될 수 있도록 지원/감독 형상관리 활동에 대해 프로젝트 관리자와 프로젝트 팀원에게 보고 및 공지 형상관리 담당자 형상관리 책임자와 협조하여 형상관리 계획에 따라 형상관리 활동을 수행 라이브러리 담당자 시스템의 개발 및 유지보수에 필요한 라이브러리를 구축하고 접근을 통제하며 형상관리 계획에 따라 백업을 수행

VIII. ISO 12207, CMMi와 형상관리 가. ISO/IEC 12207 지원 생명 주기 공정 중 형상관리

ISO 12207 지원 생명 주기 공정에 형상관리가 포함됨
ISO 12207 생명 주기 모델은 국가, 국제, 단체, 회사 표준 등 다양한 표준 수립 시 근간이 됨

구분 내용 형상관리 계획수립 형상관리 계획서로 작성되며 문서 내용은 형상관리 활동계획 활동 수행절차 및 일정계획 활동/수행 책임 조직 계획 소프트웨어 개발 또는 유지보수 팀 간의 관계를 계획하여 문서화 형상식별 기준선 설정, 버전 참조 등 세부 형상 항목을 식별 형상통제 변경 요청 사항이 식별, 기록 유지되고 변경 요청사항에 대해 분석하고 평가 형상평가 요구사항에 대한 소프트웨어 항목의 기능적 완전성과 형상항목의 물리적 완전성(설계 및 코드의 최신 기술 반영 여부)을 결정하고 보장되었는지 평가 공표 관리 및 인도 개발결과물(제품 및 문서)은 공식적으로 통과

나. CMMI의 Support Area와 형상관리

CMMI 에서도 Support 영역에서도 형상관리 프로세스가 존재한다. 형상관리 프로세스는 CMMI의 모든 프로세스 영역을 지원하기 위해 제공됨
CMMI의 형상관리 목적은 구성식별, 구성통제, 구성상태보고, 구성감사 등의 방법으로 작업 산출물의 무결성을 확보 및 유지하기 위함
다음은 형상관리의 배경도 이다. 일반적인 형상관리의 주요 기능을 포함하고 있으며 좀더 구제적이다.

IX. 형상관리 문제점 및 해결방안 가. 형상관리 문제점

구분 요소 문제점 관리적 효율성 단계별 필수 산출물 정의 어려움 동시성 개발과 산출물의 병행작업 곤란 이해도 개발자는 이중작업(불필요작업)이라 생각 기술적 표준화 산출물의 표준화된 관리 툴 부재 재사용성 산출물의 재사용성이 미흡

나. 형상관리 문제점 해결방안

구분 요소 해결방안 비즈니스 재사용성 주요산출물의 KMS 관리 산출물도출 사용자, 개발자간 주기적 회의, Rule지정 변경관리 업무변화 모니터링 후 Feedback 정보기술 자동화도구 산출물이 개발에 도움을 줄 case tool 사용 표준화 전사적인 산출물 표준 정립 Repository 산출물 내역에 대한 META DATA 이용한 저장

X. 형상관리의 효과 및 고려사항 가. 형상관리의 효과

구분 내용 프로젝트 측면 프로젝트의 체계적이고 효율적인 관리의 기준을 제공 프로젝트의 원활한 통제가능 프로젝트의 가시성 확보와 추적성 보장 품질보증의 기준선 제시 S/W 측면 S/W 변경에 따른 부작용 최소화 관리의 용이 S/W 품질보증기법 S/W 적절한 변경관리 가능 유지보수성 향상

나. 형상관리 발전방향 1) 소프트웨어 품질 향상 측면 - 효율적인 변경 통제로 품질 향상 및 생산성 향상 - 개발 과정별 산출물 관리 표준화 2) 추진 조직 및 도구 활용 측면 - 데이터, 문서의 무결성 확보를 위한 case repository 함께 수행 - 적절한 조직의 구성 및 관리 도구의 활용, 변경관리 기준 필요 다. 형상관리 시 고려사항 - 효율적인 형상관리를 위해서는 적절한 조직 구성, 관리도구의 활용, 지속적인 관리와 관리기준 등이 필요하며 이에 따른 문제해결방안 필요 - 소규모 프로젝트 일수록 형상관리 정도를 적절히 조정 - 형상관리 항목을 정하고 변경사항은 공식적인 합의에 의하여 실시 - 가동중인 S/W의 변경은 신중하게 진행 - 설정에 대한 명확한 기준 선정 및 기준형상과 파생형상에 대한 관리 및 변경의 적용 필요 라. 소프트웨어 형상관리의 최근 트렌드 - 기존의 개발 도구에 단순히 포함되는 형태에서 벗어나 ALM같이 전체 라이프 사이클을 관리하는 방향으로 진행 중 - ITIL기반의 ITSM도입으로 S/W뿐 아니라 H/W까지 전체적인 서비스 관점으로 형상관리를 진행 - EAMS, PPM등의 전사 IT 거버넌스의 한 부분으로 정의 되어, 비즈니스 영속성을 유지

변경관리와 형상관리의 차이점 1. 목적

변경관리 목적 형상관리 목적 승인 받지 않은 변경의 예방 완전 무결한 제품 정보 관리

절차

변경관리 절차: (요승 변테 문) 형상관리 절차 (식통기감) - 변경 요청 - 변경 승인 - 변경 - 변경 테스트 - 변경 문서화 - 형상 식별 - 형상 변경 통제 - 형상 기록 - 형상 감사

SW Metrics(척도)의 개념 가. Measurement/Measure/Metrics의 개념 비교

구분 설명 Measurement 어떤 현상, 특성, 결과를 숫자로 표현하는 활동 무엇인가를 자로 재고 눈으로 검사하고 기록하는 활동 Measure 측정방법의 표준, 단위로 알고자 하는 개념을 대표하는 측정 항목 FP, 본 수, 결함 수, 투입 공수 Metrics 프로세스, 컴포넌트, 시스템 속성이 숫자로 계량된 측정 항목(Measure) 두 개 이상의 측정항목(Measure)으로 계산된 복합적 지표

나. 측정의 목적 - 프로세스, 제품, 자원과 환경의 특징을 파악하고 기준을 정의하여 성과와 비교 - 계획 대비 실적 상태에 대한 평가에 활용 - 과거 데이터에 기초하여 미래를 예측할 때 활용 - 지속적인 프로세스 개선 활동에 대한 목표, 방법, 결과의 측정에 활용 다. 소프트웨어 Metrics의 정의 - 소프트웨어의 품질(quality)이나 생산성(productivity)에 대한 평가를 하는 모델 2. SW Metrics(척도)의 유형 및 유형별 측정방법 가. 측정 대상에 따른 소프트웨어 측정 유형 - 측정을 하는 대상이 어떤 것이냐에 따라 프로젝트 Metrics, 제품 Metrics, 프로세스 Metrics로 구분할 수 있음

구분 설명 Project Metrics(척도) 프로젝트 진행 관리와 관련한 측정 공정 진도 준수율, 예산 준수율, 투입공수 준수율, 교육 이행율 Product Metrics(척도) 제품 품질 평가 및 추적과 관련한 측정 규모(FP, 본 수, 화면수), 복잡도 품질특성(기능성, 신뢰성, 사용성, 효율성, 이식성) 소프트웨어 재사용율, 요구사항 변경율, 고객만족도 소프트웨어 제품에 대한 프로그램의 크기, 복잡도, 자료의 크기 기본적인 척도 Process Metrics(척도) 프로세스 성과 및 분석 관련한 측정 프로세스 준수율(이행율), 품질실패 비용율, 결함 제거율, 인스펙션 효과성, 인스펙션 효율성, 테스트 효과성, 테스트 효율성 제품 개발에 걸리는 시간, 드는 비용, 일정 등의 예측과 현재 진행상황을 알아보기 위한 척도

나. 측정 방법에 따른 소프트웨어 측정 유형 - 측정 방법에 따라 직접 Metrics와 간접 Metrics로 구분할 수 있음

※ 직접 매트릭스 가. Size-oriented metrics(크기중심 매트릭스) - 소프트웨어 엔지니어링 절차에 따른 산출물을 직접 측정하여 수집함 나. Function-oriented metrics(기능중심 매트릭스) - 간접측정에 의한 정보로 품질, 신뢰도, 복잡도, 유지보수성 등이 속한다 다. Human-oriented metrics(인간중심 매트릭스) - 개발자의 태도나 툴 또는 방법 등에 대한 효율성에 대한 정보 수집 ※ 간접 매트릭스 가. Technical metrics(기술적 매트릭스) - 논리적 복잡도나 모듈화 정도 등 소프트웨어의 특성에 초점을 둠 나. Quality metrics(품질 매트릭스) - 사용자 요구사항에 대한 소프트웨어의 품질척도를 explicit & implicit 하게 표시 다. Productivity metrics(생산성 매트릭스) - 소프트웨어 엔지니어링 절차에 대한 출력에 초점을 둠 3. SW 품질관점의 Metrics(척도) 및 측정 프로세스 가. 소프트웨어 품질 관점의 Metrics

유지보수성 : 프로그램 모듈화 정도, 복잡도, 오류발생 빈도, 문서의 품질 등
신뢰성 : 단위 시간에 시스템이 오류 없이 작동될 확률, 시스템이 제대로 가동시간을 설치된후 경과한 시간으로 나눈 값으로 나타냄 나. SW 측정 프로세스

단계 설명 각 단계 결과 소프트웨어 품질 요구사항 설정 원하는 품질인자들을 선택하고, 우선순위를 부여 품질요구사항, 품질매트릭 기본구조 SW 품질 매트릭스 식별 관련 매트릭들을 선택하고 선택한 매트릭을 어느 단계에서 적용 결정 매트릭 집합, 매트릭 명세서 자료수집 매트릭 구현 도구 도입 및 계산에 필요한 기초자료 수집 자료항목 명세서, 비용효과 분석 SW 품질 매트릭스 계산 SW 개발주기 각 단계에서 매트릭 계산 매트릭/자료 항목 추적성 행렬 SW 품질매트릭스 결과 분석 적용결과 분석, 문서화 개발과정 조정, 통제 및 평가 분석결과보고서, 개발과정 변경계획 SW 품질 매트릭스 검증 매트릭이 품질인자 등을 예측 하였는지 검증 검증결과

SW Metric 활용 및 활용 효과 가. SW Metric(척도) 활용
관리자입장 : 개발비용 산정시, 산출물 품질 확인시, 상업목표 설정시, 개발방법, 도구유용성 평가시
개발자입장 : 개발 중 품질 수준 확인시, 품질요구사항 명세화시, 인증목적으로 평가시 나. SW 품질 Metri(척도) 활용 효과
SW 개발 주기 동안에 SW 품질의 요구사항이 만족되고 있는지를 좀 더 객관적으로 평가 가능
주관적인 요소를 가능한 배제할 수 있고, 품질을 정량적으로 가시화할 수 있어 개발자나 관리자가 유용한 정보를 얻을 수 있음

SW 테스트, 유지보수 용이성 평가의 기준, 소프트웨어 복잡도 가. 소프트웨어 복잡도 정의
모듈의 결합도/상속구조/LOC 등의 SW 복잡도를 정량적이고 종합적으로 평가하기 위한 SW특성 나. 소프트웨어 복잡도가 미치는 영향

특징 설명 테스트 집중도 테스트 비용을 최소화하기 위해 복잡한 모듈을 최선으로 테스팅, Risk Based Testing SW대가 산정근거 유지보수 단가 책정시 반영 및 변경용이성 및 수정가능성의 척도 품질기준 SW의 품질을 결정짓는 품질척도로써의 활용 가능성

다. 소프트웨어 복잡도 측정의 의의 - 시스템을 어느 정보의 수준까지 시험해야 하는지 결정하는 근거를 제공 - 시스템을 개발하는데 어느 정보의 노력을 소요해야 하는지를 결정하는 근거 제공 - 복잡도가 높은 경우, 일반적으로 많은 장애가 유발될 가능성이 크므로 보다 정밀한 시험이 요구됨 4. McCabe의 회전 복잡도 가. 상세 설계가 완료된 후 사용할 수 있으며, 프로그램의 제어 흐름도를 기반으로 분석 나. 프로그램 구조의 복잡도를 순환적 복잡도(Cyclomatic Complexity)로 측정한 분석법 다. 순환적 복잡도는 흐름 그래프(Flow Graph)에 의해 측정되며, 이 그래프는 프로그램 라인을 표시하는 노드(Node)와 수행 경로를 표시하는 화살표(Arrow)로 나타낸다. 복잡도 : V(G) = 화살표 수(A) - 노드 수(N) + 2

라. MaCabe 복잡도에 따른 품질을 다음과 같이 평가 - 복잡도가 5 이하인 경우 : 간단한 프로그램 - 복잡도가 5~10인 경우 : 구조적이며 안정된 프로그램 - 복잡도가 20이상인 경우 : 문제 자체가 매우 복잡하거나 구조가 필요이상으로 복잡한 프로그램 - 복잡도가 50이상인 경우 : 비구조적이며 불안정한 프로그램 5. Halsted의 소프트웨어 사이언스 가. 복잡도를 측정하는 척도 - 기본적으로 코드가 만들어진 후 또는 설계가 완성된 후에 측량할 수 있는 방법 - 프로그래밍 언어와 무관하게 연산자와 피연산자의 종류와 발생빈도 간의 관계로 복잡도를 측정 나. 구성요인 - n1 : 프로그램내에 나타나는 연산자(operator)의 종류 - n2 : 프로그램내에 나타나는 피연산자(operand)의 종류 - N1 : 연산자의 총 발생 빈도수 - N2 : 피연산자의 총 발생 빈도수 다. 공식 - 프로그램 길이(length) : N = n1 log2 n1 + n2 log2 n2 - 프로그램 부피(volume) : V = N log2(n1 + n2) - 프로그램 레벨(level) : L = 2/n1 * n2/N2 - 프로그램 노력(effort) : E = V/L - 4가지 프로그램의 문법요소에 의해 복잡도 측정 (n1/2)*(N2/n2)

소프트웨어 복잡도를 활용한 Risk Based Testing
Cluster Defect 의 테스트 원리에 따라 20% 의 복잡한 모듈에 80% 의 버그가 있을수 있음 (파레토 법칙)
한정된 예산과 인력/시간을 고려 복잡도가 가장 높은 모듈을 중점적으로 테스팅 수행
복잡한 코드 구분을 집중테스트하여 SW 결합을 최소화 시킴

품질

소프트웨어 품질 가. 정의
소프트웨어 기능, 성능 및 품질에 관련된 제반사항에 있어 소프트웨어가 명시된 요구사항 및 내재된 요구사항을 충족할 수 있는 ‘소프트웨어 특성의 총체’
주어진 요구사항(명시적, 묵시적)을 만족시키는 소프트웨어 제품의 특성과 생산성

구분 설명 소프트웨어 특성 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 소프트웨어 생산성 프로젝트의 성격 및 복잡도 관리자의 수준, 프로그래머 능력, 의사소통 수준 보유기술 및 재사용 수준

나. 소프트웨어 품질의 인식 배경 - 질적인 문제 : 납기 지연, 고객 요구 불만족, 과다한 유지보수 - 복잡도 증가(시스템->거대화, 고성능) - 종합적 품질보증 활동 필요성 다. 소프트웨어 품질의 특성 - 품질은 상대적 개념 : 정량적 측정 어려움, 상대에 따라 다름 - 품질은 여러 자원에 종속적 : 비용, 시간, 인력, 도구 등 - 품질은 적정선에서 타협하는 것 - 품질요소들은 상호 연관성을 가짐 2. 사용자별 및 대상자별 SW품질 관점 가. 사용자별 SW품질 관점

관점 내용 평기기준 사용자 원하는 기능을 제공하여 유용하고 쉽게 쓸 수 있고, 신뢰성 높고 필요에 따라 계속 발전하는 것 기능성, 신뢰성, 사용성 소프트웨어의 성능 및 사용 효과에 관심 개발자 좋은 설계 구조를 가지며 쉽게 유지보수할 수 있고 테스트가 용이하고 환경에 맞도록 변경 가능한 소프트웨어 효율성, 유지보수성, 이식성 개발 각 단계마다 최대한 품질 만족 유지보수자 명확한 문서화와 이해가 용이한 코드 유지보수성 프로젝트 관리자 표준에 따라 제한된 비용과 기간 내에 기능적 요구사항을 구현하는 것 Verification & Validation 전반적인 품질, 요구수준 만족도에 관심 인증 SW 사용자에게 파급효과가 큰 패키지 SW 대상 반복성, 재생성, 공정성, 객관성

나. 대상별 SW품질 관점

구분 Product Process 평가관점 품질자체 측정/검토 프로세스 향상/심사 장점 SW 품질에 대한 전문적 판단의 객관화 일단 수립되면 많은 종류의 제품에 적용 가능, 평가기간 짧음 테스트 결과는 제품품질과 직접적 연관 단점 제품의 전체 테스트는 비용/시간소모, 최신 SW제품은 전통적인 접근방법으로 평가 어려움 소규모기업에 적용하기 어려움, 제품품질을 직접적으로 평가하지 않으므로 연관성이 다소 부족함 경우에 따라 품질보증시스템이 부적합할 가능성 있음

소프트웨어 품질요소 가. 주요 결정 요소 : SW의 결함(failure), 원시코드에 포함된 오류 나. SW 운용상의 장애 초래 : 분석, 설계 및 구현단계에서 유입된 오류 다. 품질요소(McCall)

분류 종류 내용 제품 개정 (업그레이드) 유지보수성(Maintainability) 에러가 발견되었을 때 쉽게 정정될 수 있는 것 융통성(Flexibility) 새로운 요구사항에 접하여 쉽게 수정될 수 있는 것 테스트 용이성(Testability) 쉽고 완전하게 테스트될 수 있는 것 제품 전환 (플랫폼 변경) 이식성(Portability) 하나 이상의 하드웨어 환경에서 운용되기 위해 쉽게 수정될 수 있는 것 재사용성(Reusability) 시스템의 일부나 전체가 여러 응용 부분에서 사용될 수 있는 것 상호운영성(Interoperability) 다른 시스템과 정보를 교환할 수 있는 것 제품 운영 (소프트웨어 운용) 정확성(Correctness) 사용자의 요구 기능을 충족시키는 정도 신뢰성(Reliability) 정확하고 일관된 결과로 요구된 기능을 수행하는 것 효율성(Efficiency) 최소한의 컴퓨터 시간과 기억 장소를 소요하여 요구된 기능을 수행하는 것 통합성(Integrity) 시스템 소프트웨어나 데이터의 독단적인 액세스 및 수정을 제어할 수 있는 것 사용성(Usability) 쉽게 배우고 사용할 수 있는 것

소프트웨어 유형과 품질 관계 및 프로세스 품질, 프로덕트 품질 가. 소프트웨어 유형과 품질 관계

유형 품질 원자력 발전소, 방사선 치료기 (인명과 재산에 손실을 가져올 수 있는 소프트웨어) 신뢰성, 정확성, 테스트 용이성 긴 수명을 요하는 시스템 유지보수성, 이식성, 융통성 실시간 응용분야 소프트웨어 효율성, 신뢰성, 정확성 보안이 중요한 소프트웨어 일관성 연동이 중요한 소프트웨어 상호운영성

나. 프로세스 품질, 프로덕트 품질 - 프로세스 품질 : CMMi, SPICE - 프로덕트 품질 : ISO 9126, ISO 14598, 정형화된 검증 방법, 인스펙션, 테스트와 측정을 위한 메트릭

품질보증(Quality Assurance, QA) 가. 정의
소프트웨어 프로젝트의 프로세스와 프로덕트에 대한 품질을 관리하고 향상시키는 작업
설정된 기술상의 요구사항과 제품이 일치한다는 것을 확신하는데 필요한 계획과 체계화된 모든 활동 나. 필요성
사용자 요구사항 최대 만족을 통한 생산성 향상
개발과정에서 품질문제점 조기 발견 및 제거 (요구단계의 에러가 코딩이후 테스트 단계에서 발견되어 비효율적임, 조기에 에러를 발견, 시정 조치를 통하여 비용 효율성 제고)
납기준수, 제품의 견고성, 제품의 확장성, 비용 노력절감, 생산성향상, 재사용성 증가
품질보증 활동 및 품질보증 작업 가. 품질보증 활동

나. 품질보증 작업

품질보증과 품질통제 비교

구분 품질보증 품질통제 목적 프로젝트 산출물 품질 확보 프로젝트 산출물 품질 확보 대상 프로젝트 수행 프로세스 프로젝트 산출물 주체 내∙외부 감사원 품질통제 부서 결과 철저한 품질관리를 적용한 프로젝트 수행을 보장 프로젝트 산출물이 품질 기준선에 미달되지 않음을 보장

소프트웨어 품질보증 절차 및 활동 가. 소프트웨어 품질보증 절차

나. 소프트웨어 품질보증 활동

품질보증 활동 세부 내용 형상관리 형상항목 식별, 변경사항 관리 문서관리 문서관리 절차수립, 문서작성/보관/폐기 품질기록 품질보증 계획/수행/결과를 기록 합동검토 Milestone에 따라 프로젝트의 진행상황을 공동검토 검증 및 확인 단계별 검증 및 테스트 시정조치 해결방안 수립 및 조치 위험관리 예상위험 발견/평가/통제 쟁점관리 고객 요구사항 변경 등의 쟁점분석, 대안설정 및 실행

5. 소프트웨어 생명주기별 품질보증 활동

소프트웨어 품질관리 가. 소프트웨어 품질관리(Quality Management) 정의
주어진 요구를 만족하는 제품 혹은 서비스의 질을 보존하는데 필요한 제반 기법과 활동
SDLC 각 단계별 에러의 탐지 및 수정(공정) 나. 소프트웨어 품질관리의 목적

평가항목 목 적 기술지원에 대한평가 적합한 기준선정, SW품질 예측 자원에 대한 평가 적합한 자원 및 비용 산정 프로세스에 대한평가 SDLC 프로세스의 평가 제품에 대한 평가 인수시험, 산출물 평가, 타제품과 비교(패키지 도입)

소프트웨어 품질 관리 체계 및 요소 가. 소프트웨어 품질 관리 체계

품질통제를 통해 제품의 품질을 확보하고 품질관리를 거쳐 품질보증으로 넘어가면 프로세스의 품질이 확보되며 궁극적으로 경영자원의 품질이 확보됨.

구분 품질관리 품질경영 범위 공급자위주, 단위중심, 생산현장 중심 구매자위주, 시스템 중심, 경영전략 차원 내용 구체적/각론, 생산/제품중심 총괄적/총론, 문화/구성원행동 중심

나. 소프트웨어 품질관리의 3요소

구분 개념 품질계획 (Quality Plan) 적용할 품질의 표준을 식별하고 적용할 방법을 결정하는 활동 품질보증 (Quality Assurance) 개발중인 소프트웨어가 적절한 품질표준을 만족하는 확신을 제공 품질 시스템을 구현하는 모든 체계적인 활동 품질통제 (Quality Control) 작업 결과가 적절한 품질표준에 부합되는가를 위해 특정 산출물을 모니터링하고 불만족 결과에 대한 원인제거 방법을 확인

소프트웨어 품질평가 유형

평가기술 내용 대표모델 제품 품질 평가 IT프로젝트를 진행하거나, 완성된 IT제품에 대해 기능성, 신뢰성 등을 평가하는 기술 ISO/IEC9126 14598,12119 프로세스 품질 평가 IT프로젝트를 진행하거나 IT를 운영함에 있어 프로세스가 수립되어 있고 체계적으로 운용되고 있는지를 평가하는 기술 CMMI, SPICE ISO 12207 경영측면 품질 평가 기관이나 회사를 경영함에 있어 소프트웨어 품질을 향상하기 위한 품질경영 기술 IT 6시그마 ISO 9000

소프트웨어 품질관리의 문제점 및 개선방안 가. 소프트웨어 품질관리의 문제점
소프트웨어 품질 특성의 비표준화로 인한 객관성결여
품질평가를 개발 완료 후 실시하므로 유지보수 비용증대와 생산성 저하
품질평가 점검항목이 개발자 중심이어서 사용자 요구의 충분한 반영이 어려움 나. 소프트웨어 품질관리의 개선방안
표준화된 소프트웨어 품질특성을 기준으로 평가
제품중심보다 프로세스 중심의 품질관리를 통하여 개발 후 개선 및 위험 최소화
소프트웨어생명주기와 품질관리 활동 가. 소프트웨어 생명주기와 품질관리 활동

소프트웨어 품질의 비즈니스적 관점 도입 소프트웨어 품질비용의 개요 가. 소프트웨어 품질비용의 정의
SW 결함 감소 등 SW의 품질 향상을 위해 수행하는 품질관리와 관련된 활동비용 나. 소프트웨어 품질비용 종류
일정품질 : 일정품질을 달성하기 위해 투자하는 비용(예방비용, 평가비용)
실패비용 : 품질결여로 파생된 비용(내부 실패비용, 외부 실패비용)
소프트웨어 품질비용 항목 및 특징 가. 소프트웨어 품질비용 항목

구분 지표 수집 데이터 항목 예방비용 프로젝트 관리 계획수립, 통제 교육기술 지원 교육 및 기술 지원 예방품질 활동 프로세스 점검, 산출물 검토 자원관리 백업, 보안 관리 평가비용 평가품질활동 장비검수, 동료검토, 고객검토, 감리 테스트 단위, 통합, 시스템, 인수 테스트 내부 실패비용 내부 실패, 품질활동 장비검수, 동료검토, 고객검토, 감리 후 결함 조치 테스트 단위, 통합, 시스템, 인수 테스트 결함 조치 외부 실패비용 결함 오픈이후 결함조치 납기지연 프로젝트 납기 지연

나. 소프트웨어 품질비용 특징 - 조직의 능력수준(CMMI)이 높아지면 예방비용, 평가비용은 조금씩 늘어나지만 실패비용은 현저하게 감소(CMMI 1단계 : 총 품질비용 전체 개발비의 60%, CMMI 5단계 : 총 품질비용 전체 개발비의 20%) - SW공학수준이 떨어지는 조직일수록 품질비용이 많이 발생 - 예방비용을 늘리면 납기를 넘기는 비율과 프로젝트 비용이 초과되는 비율이 줄어듦

프로덕트 품질 가. 내부 품질
외부 환경의 영향을 받지 않고 객관적으로 측정할 수 있는 특성
프로그램의 크기나 제어흐름의 복잡도, 모듈의 응집력, 결합도 등은 객관적으로 측정할 수 있는 내부 특성 나. 외부 품질
외부 특성의 정확한 메트릭이 어렵고 외부환경에 영향을 받음

인스펙션 가. 인스펙션의 목적

목적 내용 주목적 준비하는 동안 예상되는 결함을 찾아내고 이를 회의에서 확인하기 위함 발견된 아이템이 실제 결함이라는 사실을 확인하기 위함 결함이 있다는 기록하기 위함 개발자가 수정하도록 기록을 제시하기 위함 부목적 요구에서 설계로 추적하기 위함 다음 개발 단계를 위한 기술적 기초를 제공하기 위함 프로그래밍 품질을 향상시키기 위함 라이프사이클 비용을 낮추기 위함 테스트 작업의 효율을 높이기 위함 프로그램의 유지보수성을 인식하기 위함 소프트웨어 관리의 시작과 종료에 도움을 주기 위함

결함이 있다는 사실을 합의하는 것이 주목적이며 해결책을 찾는 것은 설계 작성자나 프로그래머의 몫 나. 인스펙션의 정의 1) 설계서, 코드등의 중간 산출물을 검사하여 결함을 발견 및 SW품질 개선과 비용절감을 위한 품질보증기법 2) 타인에 의한 Inspection은 궁극적으로 수준 높은 디버깅이 가능함
Walkthrough와 인스펙션의 비교

구분 Walkthrough Inspection 목적 산출물 개선/보완, 대안검토, Issue해결, 해당 산출물에 대한 교육 산출에서 결함 식별 및 제거 형식 Informal Review Formal Review(공식적인 절차를 따른다) 대상 Work Product Draft Completed Work Product 착수기준 산출물 작성 과정에서 필요에 의해 산출물이 정의된 기준에 도달(완성도) 수행결정 해당 산출물의 Author가 수행 여부 결정 프로젝트 팀 차원에서 수행여부 결정 특징 검토대상 산출물에 대한 사전검토 없이 검토회의를 통해 즉석에서 의견을 받아 이를 기록하는 검토형태 검토대상 산출물을 사전에 배포하여 Reviewer별 개별검토 후 검토회의를 실시하여 사전에 식별된 결함을 토대로 결함을 확정하는 검토형태 결함 데이터 측정 및 보고 보통 미수행 반드시 수행 장점 검토하는데 투입되는 시간이 최소 사전검토를 실시하였기 때문에 결함식별 최대화 단점 - 작성자가 사실을 왜곡(약점을 숨김)할 수 있음 - Inspection에 비해 중요한 결함 발견이 어려움 검토계획수립 및 사전검토를 위해 별도의 노력이 필요

인스펙션의 효과

구분 내용 필드서비스 비용절감 고객 사용 단계에서 발견되는 Defect의 수 감소 테스트 시간감소 테스트에서의 블로킹 문제 발생 가능성 감소 전체 테스트 시간 단축 재작업 시간단축 문제결정시간 재통합 비용 재테스트 비용 재포장 / 재배포 / 재설치 비용

인스펙션의 종류 가. 시스템 설계 인스펙션 1) 정의 : 모듈의 전반적인 설계나 기능을 점검 2) 주관심사 : 소프트웨어 요구, 성능 명세 관련 사항과 인터페이스 설계 3) 인스펙션 사항
설계 작업의 입력(계약 등)
하드웨어 자원에 대한 기능 할당
기능 흐름
타이밍, 동기화에 대한 설계
인터페이스
분할 과정
모듈별 설계 정의 4) 고려사항
인스펙션 대상은 새로 개발한 모듈이나 수정하는 모듈
이미 개발된 모듈은 간단히 인터페이스만 점검
성능에 큰 영향을 받으므로 자원의 효율성에 대한 예측과 이에 대비한 설계 검토 필요
하드웨어와 연관된 경우 시스템 엔지니어링 설계 부서와도 긴밀히 협조 나. 상세 설계 인스펙션 1) 정의 : 시스템 전체 설계의 목적을 반영하도록 각 모듈의 설계가 잘되었는지 검사하는 과정 2) 인스펙션 사항
설계를 프로그래밍 언어로 바꾸기 전에 시스템 설계의 목표가 설계에 잘 반영되었는지 점검
프로시저 사이의 인터페이스가 잘 되었는지 모듈의 구조와 입출력, 모듈 안의 작업이 전체 성능에 영향을 주는지 검사 3) 고려사항
상세 설계 인스펙션이 끝나기 전에 코딩 작업을 시작하면 안됨 다. 코드 인스펙션 1) 정의 : 새로 작성된 프로그램이나 다른 시스템에서 개발된 프로그램을 수정 2) 목적
코드가 요구명세와 설계명세 및 인터페이스 명세에 적합한지 검사
설계가 정확히 프로그래밍 언어로 바뀌었는지 점검
코드의 품질을 동료가 점검
오류를 조기에 파악
코드가 모듈 사이의 인터페이스 요구를 만족하는지 검사
모듈 테스팅 명세를 미리 검토
적당한 테스트 도구와 환경이 있는지 확인
모듈 테스팅을 착수할 수 있는지 결정
소프트웨어 프로덕트가 계약이나 국제 표준 또는 규칙에 맞는지 점검 3) 고려사항
컴파일 오류가 없는 것이 확인된 프로그램만 코드 인스펙션 진행
코드 인스펙션이 끝난 후에야 모듈 테스팅 진행
인스펙션 과정
인스펙션 과정의 책임과 권한은 주재자(moderator)에 있음

단계 내용 계획 주재자가 인스펙션의 작업과 과정을 확립하는 단계 인스펙션 팀을 결정 팀 구성원이 인스펙션을 잘 준비할 수 있는지 확인 인스펙션 할 대상이 지켜야할 규격을 준수하고 있는지 확인 체크리스트를 이용하여 인스펙션 착수조건에 부합하는지 결정 사전 교육의 필요성을 결정 인스펙션 회의 장소를 결정하고 확보 인스펙션 회의 일정과 장소를 예약 인스펙션 팀 구성원과 관계자에게 회의 시간과 장소를 알려줌 인스펙션 팀 구성원에게 검토 역할을 할당 사전교육 인스펙션의 대상을 제작한 엔지니어가 인스펙션 팀 구성원을 대상으로 하는 간단한 교육 소프트웨어를 간단히 설명하거나 어떤 작업이 어떻게 수행되었는지, 어떤 인터페이스가 있으며 기능은 무엇인지 설명 준비 인스펙션 팀 멤버가 인스펙션 자료를 받고 인스펙션 회의를 통보 받았을때 시작 인스펙션 회의 통보는 리뷰 할 자료의 분량과 복잡도에 따라 인스펙션에 필요한 최소 소요시간을 고려하여 결정 인스펙션 회의 발견된 결함을 팀 구성원이 모여 논의 수정 발견된 결함을 면밀히 살펴보고 필요한 부분을 수정 후속조치 인스펙션에서 발견된 모든 결함이 수정되었는지 확인

I. 품질보증의 고효율성 기법 동료검토(Peer Review)의 개요 가. Peer Review의 정의 - 작업자의 동료들이 사전에 정의된 절차에 따라 수행하는 소프트웨어(work product)에 대한 검토 - 결함을 발견하고 개선하기 위한 목적으로 수행 나. 동료 검토의 목적 1) 조기에 작업 산출물의 결함을 효율적으로 제거하는데 초점 2) 동료 검토를 통해 최종 산출물과 예방 가능한 결함에 대한 이해력 증진 3) 정해진 절차에 따라 동료 산출물을 검토하여 결함 또는 변경이 필요한 부분의 식별 4) 프로젝트에서 정의된 소프트웨어 산출물에서 동료 검토 대상 산출물 식별 과정도 포함 다. 동료 검토의 특징 1) 검토는 작성자를 위하여 동료가 수행 2) 검토는 참가자 별도 역할을 가지고 있는 구조적인 프로세스 3) 검토 담당자는 사전에 지정되며 검토회의가 시작 되기 전 작업 산출물에 대해 이해하고 질문을 생성 4) 검토 및 결함 데이터를 기록하고 분석하여 검토 프로세스의 효율성을 감시하기 위하여 사용 II. Peer Review의 절차 및 R&R 가. 동료 검토 절차

나. 동료 검토에서의 역할(Role)

구분 역할설명 프로젝트 관리자 - 동료검토 계획을 수립, 문서화 - Review를 수행할 자원 할당, 교육 훈련 지원 - 중재자 선정 작성자 - 검토의 대상인 작업 산출물을 작성 - 검토회의에 필요한 작업 산출물, 관련 표준, 절차와 같은 제반 검토자료 배포 - 작업 산출물에 대한 재작업 수행 검토자 - 작업 산출물을 체크리스트와 관련 자료를 참조하여 검토하고 결합을 식별 - 기능평가, 요구사항, 설계 반영 확인, 인터페이스 분석 수행 - 동료검토 준비 보고서에서 식별한 결점 리스트를 검토회의 이전에 중재자에게 제출 중재자 - 검토회의 참석자의 선정, 역할을 할당 - 시전 검토회의 필요 여부 확인, 필요시 일정 수립 - 작업 산출물 배포확인 - 검토회의 소집, 제반 활동 - 검토회의에서 발견된 결함들이 모두 제거 되었는지 검증 - 검토에 대한 재검토 필요성 판정, 검토여부 결정 발표자 - 작업 산출물의 분석, 이해하여 검토회의시 감독 - 산출물의 논리적 구성 부분 식별, 항목의 의미 부연설명 기록자 - 검토결과를 동료검토 보고서에 기록, 식별된 결함을 promise system에 입력 품질보증 담당자 - 동료검토가 계획대로 수행 되었는지 확인 - Promise system에 입력된 data 완료확인

III. Peer Review의 형태(SW 품질보증 기법의 비교)

구분 Management Review Technical Review Software Inspection Walkthrough 목적 - 진행상태를 점검하고 시정조치를 취하도록 함 - 스케줄과 계획의 진행상태를 확정 명세서와 계획에 대한 적합성 평가 및 변경의 무결성 보증 결함을 찾고 해결책을 검증 결함을 찾고 대안을 시험하고 학습수단으로도 활용 추천규모 2명이상 3명이상 3~6명 2~7명 참석자 경영자, 분야별 관련자 개발자 문서화된 공식적인 참석대상자 개발자 리더쉽 선임관리자 선임 엔지니어 훈련된 중재자 개발자 본인 자료량 목적에 따라 많음 목적에 따라 많음 상대적으로 적음 상대적으로 적음 산출물 경영검토보고서 기술검토보고서 검사보고서와 결함목록 검토회보고서

Walkthrough를 통한 교육을 통해 의견일치를 이룰 수 있으나 Inspection은 품질이나 프로세스의 품질을 증진할 수 있음 IV. 동료 검토를 위한 유의사항 및 성공요건 가. 동료 검토를 통한 평가시 유의 사항 1) 평가 가능한 Peer Review 결과
Peer Review 실시가 잘 진행되고 있는지 관리자 평가
얼마나 많은 Peer Review에 참석해서 Peer Review에 기여를 했는지 개발자를 평가 2) 평가가 부적절한 Peer Review 결과
Peer Review에서 누가 결함을 많이 찾았나 평가에 긍정적으로 반영
Peer Review에서 발견된 결함의 수를 해당 산출물 작성자에게 부정적으로 반영
Peer Review 통계 데이터를 이용하여 포상 또는 제제 나. Peer Review의 성공 요건 1) 기업에서 정책적으로 Peer Review를 추진
최초 Review시 많은 시간을 뺏기게 되어 Peer Review 정착 이전이라면 개발자들끼리의 Peer Review 수행 시 대부분 실패
회사에서 Peer Review 담당자를 지정해 주어 제도와 자원을 지원해야 함 2) 개발 일정에 Peer Review를 포함
Peer Review가 오히려 개발 일정을 단축시킴
테스트 기간이 절약되며 유지보수 비용이 절약됨
초보자들의 역량이 증대됨
중복 코드의 제거가 가능해짐 3) 실제 동료를 적극적으로 Peer Review에 참여 시킴
동료들간 서로 리뷰를 하면서 결함을 찾아야 함
자주해야 함

소프트웨어 공학 기술

소프트웨어 공학 기술 가. 컴포넌트 기반 개발(Component Based Development)
이미 만들어진 컴포넌트를 조립하는 형태로 개발하려는 시도 나. 웹 엔지니어링
웹 기반 소프트웨어의 확산과 함께 웹 프로그래밍의 특성에 맞는 프로세스와 구조에 대한 이해와 연구가 필요 다. 정형적 명세(formal specification)
결함이 없는 높은 품질의 소프트웨어를 개발하기 위하여 수학적 접근 방법을 사용하며 정확한 명세를 작성
프로그램에 표현될 논리를 정확히 표현하고 이를 근거로 프로그래밍 하여 오류를 줄임 라. 익스트림 프로그래밍
분석, 설계 등의 문서화 작업보다는 소프트웨어 개발 즉 프로그램 작성과 테스팅에 더 초점을 두는 애자일 방법중의 하나
고객참여, 지속적 통합, 리팩토링, 페어 프로그래밍 등 여러가지 철학을 담고 있음 마. 관점 지향 프로그래밍(Aspect-oriented Programming)
시스템의 요구가 하나의 클래스에 캡슐화되지 않고 널리 퍼져 있는 것을 애스팩트로 정의하여 직조에 의하여 실행되는 프로그래밍 바. 웹서비스와 SOA(Service Oriented Architecture)
네트워크상에서 사용할 수 있는 서비스를 이용하여 소프트웨어 애플리케이션을 구성하는 아키텍처 스타일

개발 생산성과 품질을 높이기 위한 컴포넌트 기반 개발(CBD)의 개요 가. CBD(Component Based Development, CBD)의 정의
재사용 가능한 컴포넌트의 개발 또는 상용컴포넌트들을 조합하여 애플리케이션 개발 생산성, 품질을 높이고 시스템 유지보수 비용을 최소화 할 수 있는 개발 방법론
기 개발된 S/W 컴포넌트를 조립하여, 새로운 시스템을 구축하는 방식으로 OOD의 단점인 재사용을 극대화 한 개발방법론 나. 컴포넌트 개발 과정
응용 시스템에서 공통적인 요소들을 일반화 및 캡슐화하여 컴포넌트 라이브러리로 구성
새로운 시스템을 구성할 때 라이브러리에 있는 컴포넌트를 선택하여 필요에 따라 약간 수정하고 이들을 조립하여 연결하는 접근 방법 다. CBD 방법론의 등장배경

구분 설명 기술적 측면 - OOP에는 Binary 형태의 표준이 없음 - OOP의 각 객체는 같은 컴파일러 사용 프로세스 측면 - 실제 재사용 가능한 소프트웨어를 이용한 개발이 거의 없음 - 대규모 프로젝트에서는 확장성 떨어짐 대외적 측면 - Software 위기 극복 - 기업의 업무형태의 변화

라. CBD 방법론의 특징

특징 내용 생산성 실행기반의 재사용을 통한 개발시간 단축 컴포넌트 조립을 통한 개발 형태로 인해 개발자의 생산성 향상 변경용이성 요구사항변화 수용에 안정적 신속한 변경 가능 업무변경에 따른 위험 최소 다른 컴포넌트에 영향을 주지 않고 기능 추가 용이 관리용이성 독립적인 컴포넌트 단위의 관리로 복잡성 최소 독립적인 개발과 배포가 가능하여 대체 시 편리

클래스와 컴포넌트의 차이점 및 개발 방법 가. 클래스와 컴포넌트의 차이점

클래스 컴포넌트 논리적인 측면이 강함 물리적 측면이 강함 소스코드의 형태 바이너리 코드의 형태 클래스의 연산에 의해서 기능이 정의 인터페이스에 의해서 기능이 정의 설계 단위 구현 단위

나. 컴포넌트 기반 개발 방법 - 컴포넌트 기반 소프트웨어 개발 프로세스는 두 가지 병행 작업으로 이루어짐 - 소프트웨어 개발에 사용될 컴포넌트를 구성하는데 필요한 작업(도메인 엔지니어링과 컴포넌트를 사용하여 시스템을 구성하는 컴포넌트 기반 개발) - 도메인 엔지니어링 작업 : 컴포넌트를 잘 분류하고 사용자 요구를 분석하는 도메인 분석과 소프트웨어 구조를 잘 모델링 하여 구조에 맞는 컴포넌트를 갖춤 3. 컴포넌트 특성 가. 패키지 단위 - 제공하는 인터페이스 리스트 : 인터페이스 명세만 가지고 있는 다른 패키지의 의하여 import - 요구되는 인터페이스 리스트 : 제공하는 인터페이스 리스트와 같이 별도의 패키지로부터 import - 외부명세 : 제공 및 요구되는 외부동작에 대한 명세 - 수행코드 : 다른 컴포넌트와 결합 - 검증코드 : 컴포넌트 사이의 연결이 바로 되는지 결정할 때 사용되는 코드 - 설계 : 명세를 만족하기 위하여 행한 작업과 관련된 모든 문서 및 원시코드 나. 독립된 배포 단위 : 다른 컴포넌트와 잘 구별되는 형태로 전달 다. 제공되는 인터페이스와 요구되는 인터페이스 명세 - 내부 충실(self contained) : 구현에 대한 지식이 없어도 컴포넌트를 이용하여 설계 - 대칭적(symmetrical) : 구현된 서비스만 명시, 예상된 서비스는 명시하지 않음 라. 인터페이스와 구현을 완전히 분리 - 컴포넌트 소프트웨어는 구현과 인터페이스 명세를 완전히 분리 - 인터페이스 명세 : 컴포넌트가 무엇을 제공하고 사용될 때 무엇을 요구하는지 정의 마. 컴포넌트 조립 - 컴포넌트를 플러그인 하기 위하여 다른 컴포넌트가 제공하는 인터페이스와 요구하는 인터페이스를 연결 4. 컴포넌트 개발 방법론 - 컴포넌트 기반 개발은 기존 방법에 비해, 소프트웨어의 재사용성을 높이고, 개발 기간을 단축시킴 - 컴포넌트는 개발자에게 다른 컴포넌트 및 모듈들과 상호작용하기 위한 인터페이스를 제공 - COTS(Commercial Off The Shelf)는 외부에서 구입하는 상용 컴포넌트를 지칭 - 컴포넌트는 독립적으로 실행가능하며, 바이너리 단위의 재사용을 지원하고 인터페이스를 통하여 다른 컴포넌트와 결합 5. CBD 방법론의 구축 절차 및 구축 단계 가. CBD 구축 절차 개념도

CD(Component Development) : SW 개발에 필요한 부품을 만드는 작업
재사용 목적 상 해당 도메인에 대한 분석이 핵심사항
CBD(Component Based Development) : 컴포넌트들을 조립하여 SW개발 나. CBD 방법론의 구축 단계 및 산출물

단계 액티비티 산출물 요구파악 요구사항 이해 요구사항 기술서, 용어사전, 개념 모델 요구사항 정의 유즈케이스 모델 분석 및 설계 요구사항 분석 객체 모델, UI 설계서 아키텍처 정의 아키텍처 기술서 컴포넌트 설계 인터페이스 명세서, 컴포넌트 명세서, 컴포넌트 설계서 데이터베이스 설계 데이터베이스 설계서 구현 개발표준 정의 개발표준 정의서 코드 구현 플랫폼 종속적 코드 테스트 테스트 계획 테스트 계획서 테스트 수행 및 보고 컴포넌트 테스트 보고서, 통합테스트 보고서, 인수테스트 보고서

CBD 방법론의 종류 및 비교 가. CBD 방법론의 종류

종류 특징 RUP - 유즈케이스 중심적, 아키텍처 중심적, 반복 점진적 - 4단계(Inception, Elaboration, Construction, Transition) - 6개 Core Disciplines(Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment) - 3개 Supporting Disciplines(Configuration & Change Management, Project Management, Environment) Catalysis - 요구분석(Requirements), 시스템 명세(System Specification), 아키텍처 설계(Architecture Design), 컴포넌트 내부 설계(Component Internal Design)의 절차 - Business, Component Spec, Internal Design의 세 가지 레벨 - Collaboration, Type, Refinement의 세 가지 모델 구성요소 - 추상화 (Abstract), 구체화 (Precision), 조립부품(Pluggable Parts)의 세 가지 원칙 - 정형화된 구체적 절차 없이 개략적 개념만 제시, 비선형적 절차 마르미-Ⅲ - 유즈케이스 중심, 시스템 개발 초기에 견고한 아키텍처 구축 - 계획, 요구획득, 아키텍처, 반복/점진적인 미니 프로젝트, 인도 단계를 거쳐 종료 - 절차서, 기법 정의서, 양식, 적용사례가 함께 제공 Select Perspective - 실무 경험을 토대로 만들어져 실용적인 지침과 안내서 풍부 - 정렬(Align), 아키텍트(Architect), 조립(Assemble)의 세 단계 - LUCID 기법(Linkage to the Business, Use Case Model, Class Model, Integrated Model, Data Model/Develop/Test & Deploy)

UP(Unified Process) => 도입(inception), 정련(elaboration), 구축(construction), 전이(transiton)의 4단계로 시스템 개발 과정을 구분 => 반복(iteration)을 함으로써 사용자 피드백을 통하여 요구사항을 만족시키는데 효과적 => 점증적(incremental) 접근방법을 사용, 즉 개발과정이 반복적으로 수행되면서 시스템의 구현 기능이 점증적으로 추가
CBD 방법론 핵심 성공요인 및 향후 전망 가. CBD 방법론 핵심 성공요인

구분 내용 아키텍처 중심적 아키텍처 중심 개발을 통한 가시성 확보, 위험 조기 식별 및 대응 엔지니어링 도구 자동화된 툴을 통해 생산성과 정확성 향상 가능 프레임워크 기반 프레임워크 기반 개발은 개발생산성 향상 및 품질향상의 기반 역할 조직간 R&R 컴포넌트 개발팀, 솔루션 개발팀, 조직지원팀의 역할 분담 표준 및 방법론 실행환경 표준 : .NET, J2EE, CCM 개발표준 : UML기반 개발표준 및 RUP와 같은 방법론 개발팀 역량 개발팀원의 기반 기술 습득 정도, 표준 이해 및 준수 정도 재사용관리체계 컴포넌트 재사용 자산 축적 및 품질관리 체계 구축 중요 경험 축적 프로젝트 관리나 아키텍처 정립에 대한 경험과 적용 능력 중요

나. CBD 방법론 향후 전망 - 컴포넌트를 넘어 아키텍처 기반의 재사용(MDA/MDD), Product Line에 의한 재사용으로 발전 예상 - Business Architecture, Software Architecture 등의 영역별 세분화, 전문화 진행(MDA) - WEB 서비스의 출현 이후 비즈니스 컴포넌트의 진화 예상

컴포넌트 도출방법 6가지(유설 이유 복도) 1. 유즈케이스 시나리오 분석을 통한 컴포넌트 도출 2. 설계 단계의 UI 레이아웃 설계 또는 UI 네비게이션 설계시 도출 3. <> 클래스 상관관계 분석을 통한 컴포넌트 도출 4. 유즈케이스와 <> 클래스의 상관관계 분석으로 도출 5. 복잡한 비즈니스 룰 또는 알고리즘을 컴포넌트로 도출 6. 도메인 전문가에 의한 판단

SW 생산성, 상호운영성 극대화 위한 모델단위 재사용 MDA의 개요 가. MDA(Model Driven Architecture)의 정의
소프트웨어의 설계 모델을 명세하고 이를 상세 설계 모델과 코드로 변환하여 프로그램을 자동 생성하는 새로운 개발 기술 나. MDA의 등장배경
기존 미들웨어 프레임워크의 한계 : CORBA, J2EE, .NET
SW 개발, 관리, 구현, 유지보수, 배포 등 전반에 걸친 표준 모델의 정의가 필요 다. 아키텍처 기반 개발 방법간의 비교

구분 MDA SOA Product Line 관점 모델기반 아키텍처 서비스기반 아키텍처 제품관점 아키텍처 주요기법 CIM, PIM, PSM, MOF, CWM, XMI Composite APP, SOBA, SODA, ESB Core Asset, Domain 공학, APP 공학 특징 UML Profile, CBL을 통한 제약, 산출물 자동화 구현 서비스기반 재사용, 웹서비스, ebXML, Time-to-Market
지향 Repository활용, Domain 단위 재활용, 요구공학 적용

MDA의 모델분류 및 관련 표준 가. MDA의 모델분류

모델 설명 PIM (Platform Independent Model) 메타모델을 기반으로 한 독립적 모델, 구현기술과 무관하게 비즈니스의 기능과 행위를 정의 특정한 기술 플랫폼이나 기반 기술에 독립적인 방법으로 시스템을 설계한 모델 단일 플랫폼에 매여 있지 않고 프로그래밍 언어 독립적이기 때문에 다른 시스템으로의 가교 역할 PSM (Platform Specific Model) 각 구현환경에 적합한 구현모델로 자동 변환해 주는 모델, 기술 플랫폼 특성을 반영함 특정 기술에 종속적인 요구사항들이 포함된 시스템 모델 정보 실제로 동작하는 구현 코드를 만듦

PIM과 PSM 모두 UML로 기술 나. MDA의 관련 표준

표준 내용 UML (Unified Modeling Language) 객체 및 컴포넌트 시스템을 표현하기 위한 표준언어 MOF (Meta Object Facility) 모델 정보에 대한 표준적인 저장소를 제공하고 표준화된 방식으로 모델 정보를 접근하는 구조를 정의 CWM (Common Warehouse Model) 데이터 저장소 통합에 대한 표준을 정의하고 데이터베이스 모델과 스키마 변환 모델, OLAP, 데이터마이닝 모델(data mining model)에 대한 표준화된 표현 방법을 제공 XMI (XML Metadata Interchange) UML로 기술된 모델 정보의 XML 표현에 대한 표준

※ MDA 개발방식의 이점 - 기술 변화 상황에 효율적으로 대처 : MDA 방식으로 개발된 시스템은 PIM을 통해서 변경된 기술 플랫폼으로 이식이 쉽게 이루어짐 - 시스템 인프라 변화에 유연하게 대처 - MDA 방식으로 개발된 시스템은 그 시스템의 유지보수 비용이 적으며 시스템의 수명이 김 - 투자비용 보존 ※ PIM과 PSM의 분리 이점 - 플랫폼에 종속적인 사항을 고려하지 않아도 되므로 PIM 수준에서의 모델의 완전을 확인하기가 쉬움 - PIM을 통한 PSM의 생성을 통해서 기술변화에 유연하게 대처 - 시스템의 통합과 상호운영성을 PIM 수준에서 정의함으로 좀더 유연한 방식으로 해결 3. MDA기반의 SW개발 방식 MDD 가. MDD(Model Driven Development) 정의 - 플랫폼 독립적인 SW 모델로부터 플랫폼 종속적인 SW모델로 자동 변환하고, 소스코드를 자동 생성하는 방법으로 원하는 플랫폼에 맞는 SW를 쉽고 빠르게 개발하는 기술 나. MDD의 모델구조 - PIM : 비즈니스 전문가가 UML 모델링 - PSM : MOF로 정의된 PIM을 UML 프로파일로 자동 매핑 하여 생성 다. MDD의 모델 변환의 종류

모델변환 내용 PIM to PIM PIM에서 PIM으로의 변환은 PIM이 개발 단계에서 좀더 상세화되는 경우다. 상세화가 이루어지더라도 변환된 PIM에 특정 기술관련 사항이 기술되지 않음 PIM to PSM PIM이 실제 시스템의 기능을 충분하게 기술하고 있다면 기술 종속적인 정보를 추가하여 PSM으로 변환 한다. 변환된 PSM도 UML로 기술함 PSM to PSM PSM과 PSM의 변환은 PIM to PIM 관계와 같이 상세화 관계이다. 하지만 이 변환에서는 실제 구현과 관련된 정보가 포함된다. 예를 들면 컴포넌트가 실제로 실행되기 위한 컨테이너 정보, 설정 정보, 배포 정보를 추가하는 것이 이러한 변환에 해당함 PSM to PIM 기존 시스템의 구현 상황을 추상화하여 PIM 모델을 얻어내는 과정임

MDD 절차 및 MDA/MDD 고려사항 가. MDD에 의한 개발 절차 1) MDA 개발
타겟플랫폼 식별 => 메타모델 식별/정의(CWM) => 매핑기법 정의/구현(UML 프로파일) 2) MDA기반 애플리케이션 개발
PIM모델 작성 =>(MOF->XMI 매핑)=> PSM모델 작성 => 애플리케이션 완성

나. MDA/MDD 고려사항 - 기술 변화에 따라 새로운 UML profile 생성 필요 - MDA기반 도구 개발의 연구(컴포넌트 생성 및 조립도구, SW 아키텍처 재사용 시스템 개발) - OMG의 지속적인 표준화 작업과 MDA 적용사례의 계속적인 발굴이 필요 5. MDA의 개발 프로세스 및 특징 가. MDA의 개발 프로세스 1) CIM(Computational Independent Model) : Domain독립적인 요구기능을 모델링, 시스템 아키텍트가 수행, PIM과 매핑 필요 2) PIM(Platform Independent Model) : UML을 활용하여 비즈니스 요구사항을 플랫폼 독립적으로 모델링, 비즈니스 아키텍트 수행, PSM과 매핑필요 3) PSM(Platform Specification Model) : UML Profile의 확장을 통한 플랫폼 종속적인 모델정의, 개발자 수행, 자동화 도구 매핑 필요 4) 산출물 자동화 : UML, 자동화 도구를 통한 분석/설계문서, 개발Source 자동생성 나. MDA의 주요특징 - 구성요소 : XML(모델링, 분석/설계/제약), MOF(Metadata of Facility), XMI(eXtensible Metadata Integration), CWM(Common Warehouse Metamodel) - 개발특성 : Model기반의 모델링의 변환을 통한 자동화(적시성), 아키텍처 기반의 재활용, 모델간의 제약(CBL, UML Profile), 자동화된 산출물작성 - 아키텍처 기반 : CBD의 공통컴포넌트 개발, Product Line의 Core Asset 개발지원 6. MDA의 활용 및 효과적 수행방안 가. Embedded 소프트웨어, 반복수행을 위한 공통 모듈, Product Line의 Core Asset작성, 기술 위험이 적고, 잘 알려진 프로젝트개발에 적용함 나. UML 2.0의 확장 Profile의 적극 활용, Repository의 활용하여 모델을 공유하고, 형상관리를 통한 BaseLine관리, 공통 Component 구축에 우선 적용을 통한 검증수행 다. UML Profile, Metadata 표준화의 속도가 기술발전 속도에 미치지 못해 활용성 저하

UML의 확장메커니즘을 통한 MDA 지원도구, UML Profile의 개요 가. UML Profile의 정의
UML을 특정 도메인에 특화 시키기 위하여 UML 메타모델에 적절한 제한과 확장을 주어 새로운 모형을 제시하는 일종의 사용자 정의
UML2.0 에서 스테레오타입, 제약조건, 태그 정의, 태그 값을 통해 모델링 요소의 의미를 확장하는 일련의 과정 나. UML Profile의 특징 1) 플랫폼, 언어, 혹은 도메인 단위로 UML의 표현력을 확장 2) UML Profile for EDOC(Enterprise Distributed Object Computing), UML Profile for EAI(Enterprise Application ntegration), UML Profile for CORBA 등이 제시됨.

특징 설명 MDA 지원 UML 2.0을 기반으로 PIM 및 PSM 모델 생성을 지원 semantics 표현 다양하고 복잡한 소프트웨어 모델링을 위한 의미(Semantics) 기반 모델링 지원 재사용성 강화 여러 복잡한 모델링 요소들에 대해 패키징을 통해 재사용성 극대화

UML Profile의 구성요소와 활용 사례 가. UML Profile의 구성요소

확장요소 내용 Stereotype (스테레오타입) UML의 어휘를 확장 기존구성요소에서 파생 해당문제영역에 특정한 구성요소를 새로 생성 사용자 정의기반의 모델 요소들을 분류 Constraint (제약조건) UML 요소가 갖는 의미를 확장 새로운 규칙을 추가하고, 기존 요소가 갖는 의미를 수정 OCL과 같이 모델링 요소에 특정 제약사항 추가를 통한 의미를 재정의 Tagged Define (태그 정의) 모델링 요소에 추가될 수 있는 새로운 속성항목을 정의하는 요소 Tagged Value (태그 값) UML 요소가 갖는 프로퍼티를 확장 그 요소의 명세서에 새로운 정보를 나타나게 함 새로 정의된 태그에 따른 값(Value)을 표현

나. UML Profile의 유형

유형 설명 활용사례 PIM 기반 UML Profile for EDOC, EAI 플랫폼 독립적인 설계모델 생성을 위한 프로파일 생성 PSM 기반 UML Profile for CORBA, EJB 플랫폼 종속적인 설계모델 생성을 위한 프로파일 생성

다. UML Profile을 이용한 MDA 접근 방법

라. UML Profile의 활용사례

UML Profie의 활용분야 가. 특정 프로그램 랭귀지에 특화 : MDA(model driven architechture)에서 PIM모델에 UML Profile을 적용함으로써 PSM모델로 전환가능 나. 특정 도메인영역에 특화 : 수행 프로젝트에서 보다 효율적이고, 최적화된 UML 커스터마이징을 통해 효율적인 시스템 가시화 향상 다. UML Profile의 전망
UML Profile로 부터 각종 산출물을 생성할 수 있는 생성기(generator)를 지원하는 도구의 개발이 요구됨
지속적으로 변화하는 기술상황에 따라 수많은 UML Profil의 OMG를 통한 표준화가 요구됨

Ⅰ. CBD방법론의 재사용 향상을 위한 도메인 분석방안, 도메인 공학의 개요 가. 도메인공학(Domian Engineering)의 정의 - 도메인 : 특정분야에서 공통의 기능을 가지는 일련의 시스템 집합 - 도메인 공학 : 도메인 분석, 아키텍처 개발과 재사용 가능한 컴포넌트 등을 식별하여 새로운 시스템을 개발할 때 재사용 가능한 Asset을 보급하는 공학 나. 도메인 공학의 특징 1) CBD(Component Based Development) 개념의 방법론 2) Core Asset을 미리 만들어 놓고 실제 프로젝트에서 Asset을 조립하여 프로덕트를 만드는 개념(Product Line) 3) 해당 도메인(특정분야)에서 재사용이 가능한 컴포넌트를 보급

다. 도메인 공학의 필요성 1) CBD(Component Based Development)개념의 확산에 따른 S/W 재사용에 대한 요구 증대 2) 요구사항 분석 이전 단계에서 수행되는 도메인 분석에서부터 재사용에 대한 요구 증대 II. 컴포넌트 기반 도메인공학 프로세스 가. 도메인공학의 프로세스 및 단계별 설명

도메인 명세서를 작성하고, 명세서를 바탕으로 도메인을 분석하고, 컴포넌트를 추출하여도메인 아키텍처를 생성하고 도메인 컴포넌트를 구현한다 나. 도메인 공학의 단계별 설명

구분 설명 도메인 분석 (Domain Analysis) 하나 이상의 도메인을 식별하고 도메인내의 변화량을 포착한다. 도메인에 관련된 정보를 식별(identifying), 수집(collecting), 편성(organizing), 표현(representing)하기 위한 절차로, 현행 시스템과 그 당시 개발 히스토리에 대한 연구, 도메인 전문가로부터 얻은 지식, 기초 이론, 도메인에 관한 신생 기술을 바탕으로 분석 도메인 설계 (Domain Design) 도메인 분석 산출물과 소프트웨어 요구사항/설계 재사용과 일반 아키텍처(generic architecture) 연구로부터 얻은 지식으로 설계 모델을 개발하는 절차 도메인 구현 (Domain Implement) 요구사항을 재사용 가능한 컴포넌트로부터 생성된 시스템으로 옮기기 위한 메커니즘을 정의. 도메인 모델과 일반 아키텍처를 기반으로 한 재사용 가능한 컴포넌트를 식별하기 위한 절차.

※ 도메인 공학 목적 : 도메인(시스템 집단) 어느 부분이든 구현을 지원하기 위해 산출되는 RSOs(Reusable Software Objects)로 부터 도메인을 습득 및 편성하고 표현하기 위한 것 Ⅲ. 도메인 공학의 주요기법 및 유사공학과의 비교 가. 도메인 공학의 주요기법

기법 설명 SCV (Scope, Commonality, Variability) Scope 내에서 공통점과 차이점을 구별해 내는기법 Language Library개발에서 연유한 이 기법은 새로운 시각 제공 FODA (Feature Oriented Domain Analysis) Context Analysis, Domain Modeling, Architecture Modeling으로 구성 사용자의 요구사항을 반영하는 Feature 도출 ODM (Organization Domain Modeling) 형식적이고 반복적인 도출을 통해 도메인을 도출 다양성 관점, 경험기반 FAST 시스템 집합이 추상화, 명세화, 변환의 프로세스에 기반한 Textual한 표현법을 사용한 관점에서 시스템의 공통성을 식별하고 분석

나. 도메인 공학과 유사 공학의 비교

구분 CBD Product Line 도메인 공학 정의 기 개발된 S/W컴포넌트를 조립하여 새로운 시스템을 구축하는 방법 Product 개발시 Core Assets을 이용하여 여러 Product를 만들어 내는 접근 방법 특정분야의 컴포넌트를 재사용 가능한 Asset을 보급하는 공학 선개발여부 X ○ X 재사용성 재사용성 많음 재사용성 많음 재사용성 적음 도메인개념 적용여부 X ○ ○ 공통점 서비스규모는 컴포넌트 기반임

Ⅳ. 도메인 공학의 전망 가. 불필요한 컴포넌트 생성을 방지하고 소프트웨어의 재사용성을 지원하여 품질향상 및 개발기간 단축 나. 산출물간의 연관성, 다양성, 공통성 등의 속성을 효과적인 관리를 통해 생산성 향상 가능

전략적인 Core Asset의 재사용으로 동일계열 제품군 개발, Software Product Line의 개요 가. SPL(Software Product Line)의 정의
선택된 Market 또는 Mission의 특정 요구사항을 만족시키도록 관리되어지는 기능들 및 공통사항을 공유하는 Products의 그룹
SW 공학의 전체 관점에서 Domain Specific하게 재사용 할 기본 단위인 Core Assets을 미리 개발하고 실재 Product 개발시 Core Assets을 이용하여 여러 Product를 만들어 내는 접근 방법
컴포넌트가 조립될 수 있는 프레임워크를 제공하는 아키텍처를 기반으로, 필요한 컴포넌트를 선택적으로 조립함으로써 시장의 요구사항에 맞는 시스템을 생산하는 방식 가. Product Line의 등장 배경
Time to market 향상의 필요성 절감
체계적인 재사용 목표의 달성
제품 품질의 향상
Mass customization의 실현 나.Product Line의 특징
도메인 공학으로 제품간의 공통성(commonality)과 가변성(variability)을 추출하여 Core Asset 개발(전략적 재사용으로 재사용성 향상)
아키텍처 기반의 개발로 각각의 Product들을 개발시 컴포넌트(Core Asset)가 조립 될 수 있는 프레임워크 제공
리엔지니어링으로 기존의 Core Asset을 상황에 맞게 수정하여 재사용
Software Product Line의 구성도 및 핵심 활동 가. Product Line의 구성도
Core Asset 개발과 Product 개발, 관리의 3가지 핵심활동으로 구성됨. 나. Product Line의 핵심 활동

구분 내용 Core Asset 개발 - 도메인의 공통 요구사항을 추출하여 핵심 프로세스 컴포넌트를 개발 - 제품개발과 별개로 또는 제품개발 중에 진화되어 나올 수 있음 Product 개발 - 동일한 시스템 군의 Core Asset을 조립하여 개별 시스템을 개발 - 개별 제품 요구사항에 의존적 관리 - 조직적, 기술적 측면에 대한 관리 활동 - 기술적 관리 : Core Asset 개발 및 제품지원 - 조직적 관리 : 적절한 조직구조의 정의와 적당한 자원의 분배 관리 - 적용 및 확산계획 : 상태 달성을 위한 전략을 기술

Software Product Line 개발 절차와 단계별 활동 및 개발 방법 가. Product Line 개발 절차

나. Product Line 개발 단계별 활동

구분 절차 설명 도메인 공학 제품계열 계획 비즈니스 사례 분석(환경, 경제성, 시장) 제품계열 Scoping(경계구분) 제품 패밀리 분석 제품특징 파악(프로세스/서비스 모델) 제품공통성 분석(결정모델, 검증) Core Asset 개발 컴포넌트 식별, 분석, 명세화(상세화) 아키텍처 구축 애플리케이션 공학 요구정의 제품 요구사항 분석 제품 아키텍처 생성 애플리케이션 개발 제품 구현 테스트 제품 통합 및 테스트

다. Product Line 개발 방법

구분 내용 Proactive 방법 - Core Asset을 먼저 개발, 초기투자와 선행지식 필요 - 범위선정을 제일 먼저(Develop the scope first) - 새로운 제품 개발시 코드의 개발 최소화 Reactive 방법 - 하나 혹은 여러개의 product로부터 Core Asset 및 다른 제품을 도출(비용저렴, Reengineering기법 사용) - Product Line 기술을 처음 도입하는 경우 Incremental 방법 - Proactive나 Rewrite를 사용하지만, 초기부터 제품개발과정 중에 계속해서 Core Asset을 개발하는 방식 - Core Asset Base로부터 제품과 추가 Core Asset 반복 계속

Software Product Line의 이슈 및 향후 전망 가. Product Line의 이슈
각 Core Asset은 해당 Core Asset을 활용하여 제품을 개발할 수 있는 관련 프로세스 정의 필요
기술부서 보다는 상위 부서의 승인과 지원이 필요
Product Line 성공을 위해서는 아키텍처 관점이 필요
Product Line 환경과 비즈니스 모델링을 지원하는 관련 Tool 활용이 필수 나. Product Line의 향후 전망
Product Line의 성공 가능성을 높이기 위해서는, 공통으로 적용할 수 있는 핵심 Activity나 Practice의 표준 정의가 필요
Software Product Line의 기대효과 및 고려사항 가. Product Line 적용 기대효과

구분 기대효과 사업적 측면 - 특정 고객의 요구에 맞춤 개발 가능 - 비용 감소, 노동력 감소, time to market 향상 - 급격히 변화하는 시장에서 경쟁우위차지 기술적 측면 - SW 재사용의 극대화 - 개발 생산성 및 품질 향상 - System 신뢰도 향상

나. Product Line 적용시 고려사항 - 큰 규모의 초기투자와 장기간의 개발기간이 요구되므로 개발완료시기가 촉박하지 않는 프로젝트에 파일럿 형태의 적용 필요 - 새로운 요구사항에 맞추어 조립공정을 바꿀 수 있는 강건한 아키텍처가 매우 중요하며, 변화에 신속히 적응할 수 있도록 조직을 관리하는 것이 필요 - MDA(Model-Driven Architecture) 기법을 적용, SW 제품 구현을 위한 구체적인 가이드라인 제시, 프로세스를 지원하는 자동화 지원 도구와의 밀접한 연계 필요

SPL 구성요소 : 3개 Category(Process Area)와 29개 Practice로 구성

Software Engineering Technical Management Organization Management 아키텍처 정의 아키텍처 평가 컴포넌트 개발 COTS 활용 기존 존재하는 Assets 마이닝 요구공학 소프트웨어 시스템 통합 테스팅 관련된 도메인에 대한 이해 구성관리 데이터 수집, 측정, 추적 Make/Buy/Mine/Commission 분석 프로세스 정의 Scoping 테크니컬 계획 테크니컬 리스크 관리 툴 지원 비즈니스 케이스 만들기 고객 인터페이스 관리 획득 전략 만들기 자금 투자 계획 착수와 내재화 마켓 분석 운영 (수행) 조직적인 계획 조직적인 리스크 관리 조직 구성 기술적인 예측 교육

SPLA(Software Product Line Architecture)
SPL과 기존 개발방법론과의 비교

구분 SPL CBD 대상SW 사용자 맞춤형 SW 컴포넌트 기반 SW 기술개발대상 SW 생산 프레임워크 바이너리 컴포넌트 SW 핵심자원 저장소 컴포넌트 시험 및 유통 제품 조립 엔진 애플리케이션 서버 주활용분야 통신, 항공, 국방 등 공학분야 금융, 제조, 유통 등 비즈니스 분야 임베디드SW 및 패키지 개발업체 컴포넌트 개발 및 SW 개발 업체

SPL 개발 프로세스 가. Core Asset Development(Domain Engineering)
반복적인 수행으로 Products의 공통적인 부분을 찾아내고, 기존의 Core Assets을 Product의 상황에 맞게 수정하여 Products 개발의 생산성을 향상시키는 개발 단계 나. Product Development(Application Engineering)
Core Assets을 이용하여 Products를 개발하는 단계로 개발시간 단축, 품질확보를 통해 Product 개발을 체계적으로 수행 다. Management
성공적인 SPL 실행에 중요한 역할 수행
조직적, 기술적 측면의 관리 활동을 말함
올바른 조직구조 구성 및 자원할당
조정 및 감독
교육훈련 및 적절한 보상
달성 전략개발 및 의사소통
SPL 적용 계획수립 및 이행
외부와의 인터페이스 관리

SSPL 가. SSPL(시스템&소프트웨어 프로덕트 라인) 정의
제조기술과 조직운영, 산업구조 등을 포괄하는 생태계를 조성하는 소프트웨어 개발방법론 나. SSPL의 4대요소

요소 설명 대량고객 맞춤화 역량 - 고객마다 품질과 경제성, 적시출시 등의 만족도 요소를 선호하는 정도가 다름 - 단일 제품이나 서비스만으로는 다양한 고객을 만족시키기 어려움 플랫폼 - 다른 기술이나 프로세스가 만들어지는 기술 기반 - 체계적으로 재사용되는 자산 체계를 의미 - 제품라인(프로덕트 라인)은 같은 플랫폼을 공유하면서 유사한 특징을 갖는 제품군을 의미 - 내부 플랫폼을 기반으로 제품라인을 개발함으로써 개발비용과 시간을 줄이고 다수 고객을 만족시킬 수 있음 프로세스 - 작업 처리 공정을 의미 - 사용자 업무 프로세스, 개발 프로세스, 운영 프로세스를 모두 의미하며 플랫폼과 프로세스를 융합·개발해 최적화함 - 사용자, 개발자, 운영자 업무 프로세스가 플랫폼에 통합 반영돼 자동화되고 최적화되기 때문에 비용과 시간을 절약해줌 SW와 시스템의 융합 - SW와 시스템을 통일된 관점에서 개발함으로써 시스템 개발을 더욱 용이하게 해줌

다. SSPL 개념도

라. SSPL의 기대효과

기대효과 설명 경제적 효과 재사용되는 자산체계인 플랫폼 사용으로 개발비용과 시간을 절약 제품라인(제품군), 외부 플랫폼화, 고객 맞춤형 특징 등을 제공함으로써 품질과 경제성 등 다양한 고객의 요구를 충족시킬 수 있음 산업과 사회적 측면 효과 고급 산업 발전과 고급 SW 일자리 발굴이 가능

마. 도입 목적 - 고객만족도 재고, 품질개선, 제품 개량 용이성 증대, 복잡도 증가에 대한 대응력 제고 - 원가 절감, 원가 산정의 정확도 개선, 유비보수비 절감 - 제품 출시 소요기간 단축 4. EU의 적용 분야 - 자동차, 항공, 의료, 통신, 가전등 핵심산업분야 5. SSPL 성공 전략 - 비즈니스 가치에 기반을 둔 제품군 범위 최적화 -개별 고객 만족 위한 계층 플렛폼 실용화 - 재사용 자산과 가변 자산의형상, 추적, 변경의 자동화 - 제품군에 속하는 각 제품의 시장 차별화 전략 6. SW 영역의 SSPL 정책 - SW영역의 패스트 팔로우 전략화 - 반도체, 자동차, 통신, 조선등 주력 산업의 사례 - SW 공통요소(도메인)과 가변요소(애플리케이션)의 자산화 통한 개발기간 단축, 비용절감, 품질 향상 - 플랫폼,재사용 역량 극대화, 고급 인재양성, SW 시장의 셰계화 통한 경쟁력 확보 7. sspl 적용 프로세스 개념도

웹엔지니어링 가. 정의
고 품질의 웹 기반 시스템을 성공적으로 개발하고 배치하며 유지보수하기 위하여 엔지니어링 및 경영관리 원리를 확립하고 사용하는 것 나. 특성

특성 내용 네트워크 강조 네트워크상에 수행되며 클라이언트에 대하여 서비스 콘텐츠 중심 하이퍼미디어를 사용하여 엔드유저에게 텍스트, 그래픽, 오디오, 비디오 콘텐츠를 제공 계속적인 진화 보완 및 릴리즈하는 일반 소프트웨어와는 달리 웹은 시간 단위로 수정(진화)

다. 웹엔지니어링 작업 분류

분류 내용 단순 정보 단순한 내비게이션과 링크를 제공하는 읽기 전용 콘텐츠 다운로드 사용자가 해당 서버에서 정보를 다운로드 커스텀 기능 사용자가 특정한 목적으로 콘텐츠를 조작 가능 인터랙션 채팅, 게시판, 메시징 등을 이용한 사용자 그룹 사이의 의사소통 사용자 입력 양식 입력이 주된 방법 트랜잭션 중심 사용자가 웹 응용에서 내용을 채운 트랜잭션 처리 ex : 상품주문 처리 서비스 중심 사용자에게 서비스를 제공 포탈 다른 웹 콘텐츠나 서비스에 대하여 정리하여 제공 데이터베이스 접근 사용자가 데이터베이스에 질의하여 정보를 획득 데이터웨어하우스 사용자가 대규모로 모아진 데이터베이스에 질의하여 정보를 획득

웹엔지니어링 프로세스

가. 공식화 단계 - 웹 응용의 목표와 목적, 범위를 정하는 공식화 단계 나. 계획 단계 - 전체 프로젝트의 비용을 예측하고 개발과 관련된 리스크를 파악하여 자세한 개발 일정을 정의 다. 분석 단계 - 웹 응용에 대한 기술적인 요구를 확립하고 웹에 들어갈 콘텐츠 아이템을 파악, 그래픽 디자인 요구사항 정의 라. 엔지니어링 단계(두가지 작업을 병행) - 엔지니어링팀 : 웹 구조설계, 내비게이션 설계, 인터페이스 설계 - Art팀 : 콘텐츠 설계, 프로덕션 수행 마. 페이지 생성 단계 - 자동화된 도구를 이용하여 웹 페이지를 구축하는 작업 - XML, Java 애플릿, 컴포넌트 미들웨어와 연결할 컴포넌트 및 인터페이스를 통합하여 웹페이지 생성 바. 테스트 단계 - 웹 응용의 내비게이션을 테스트하여 애플릿, 스크립트, 입력 양식 등에 오류가 없는지 확인 사. 고객평가 단계 - 어떤 변경이 필요한지 요구하는 시점이며 수용된 변경 요구는 다음 프로세스에 반영 4. 웹 구조 설계 가. 정의 - 웹 응용의 멀티미디어 구조를 정의하고 템플릿을 사용하여 디자인 패턴을 적용 - 콘텐츠가 들어갈 웹 페이지들의 전체적인 구성을 설계 나. 종류

구조 내용 선형 구조 콘텐츠가 보이는 순서가 정해져 있는 구조 ex : 튜토리얼 성격의 웹 페이지 ex : 그래픽이나 비디오, 오디오를 보아야 다음에 있는 웹페이지를 볼 수 있는 형태 그리드 구조 웹 페이지 내용이 이차원적으로 분류된 구조 ex : 수평적으로는 골프채 타입을 수직적으로는 골프채 만든 회사를 보여주는 웹페이지 계층 구조 수직적으로 흐름으로 제어흐름을 통제 네트워크 구조 웹 응용 컴포넌트가 자유자재로 제어를 통제

웹 테스팅 단계 가. 웹 응용에 포함된 콘텐츠에 오류가 있는지 파악 나. 내비게이션 오류를 찾기 위하여 웹 설계 모델 검토
분석 단계에서 작성한 사용사례를 이용하여 구조와 내비게이션이 잘되었는지 검토
내비게이션이 되지 않은 부분은 링크에 오류가 있음 다. 웹 페이지 단위 테스트
단위 테스팅을 위하여 웹 페이지를 하나씩 테스트 라. 통합 테스트(웹의 구조를 고려하여 테스팅)

구조 내용 선형, 그리드, 단순 계층 구조 소프트웨어의 통합 테스팅과 같이 상향식 또는 하향식 방법을 사용 복잡 계층, 네트워크 구조 중요한 스레드부터 점차적으로 확장해 나가는 연쇄식 방법을 사용

리그레이션 테스팅 : 홈 페이지 변경 후 부작용이 없는지 확인하는 작업 마. 시스템 테스트
웹 응용 전체 기능과 콘텐츠가 잘 나타내었는지 점검
소프트웨어 시스템 테스팅과 같이 사용자에게 보이는 입력과 출력 기능 위주로 테스트 바. 환경 테스트
운영체제, 브라우저, 하드웨어 플랫폼, 통신 프로토콜과 호환성이 있는지 테스트 사. 사용자 테스트
실제 사용할 사람들을 선택하여 웹 응용을 사용하게 하고 콘텐츠, 내비게이션, 편리성, 성능을 검토

Agile 가. 정의
개발팀이 설계와 문서화 보다는 소프트웨어 그 자체에 더 초점을 도는 접근 방법
고객에게 실행되는 소프트웨어를 가능한 빨리 제공하고 여기에 대한 사용자의 피드백을 받아 변경된 요구를 다음 반복 단계에 또 반영시키려는 방법
기존의 폭포수(Waterfall) 개발과 달리 사용자, 개발자, 테스터가 하나의 조를 이뤄 사용자 시나리오 개발, 코딩, 품질 테스트를 단기적으로 한정된 시간 안에 진행해 전체 프로젝트를 수행하는 방식
애자일 개발방법론은 사용자, 개발자, 테스터가 하나의 조를 이뤄 사용자 시나리오 개발, 코딩, 품질 테스트를 단기적으로 한정된 시간 안에 진행해 전체 프로젝트를 수행하는 방식이다 나 원리

원리 내용 고객참여 고객이 개발 프로세스 전반에 걸쳐 적극 참여 고객의 역할은 시스템의 요구를 제공하고 우선순위를 정하며 반복 개발의 결과를 평가 반복적 릴리즈 여러 차례의 반복적인 사이클에 사용자의 요구를 조금씩 개발하여 릴리즈 프로세스 보다는 사람 개발 팀의 능력과 실력을 충분히 파악하고 존중하여 개인에 맡기는 스타일 변경을 포용 요구가 변경될 것을 예상하고 변경에 조화되도록 시스템을 설계 단순함을 유지 개발하는 소프트웨어 자체나 소프트웨어 개발 프로세스를 가능하면 단순하게 하고 복잡한 부분은 시스템에서 제외

나. 기존 방법론이나 개발모델의 문제점

구분 내용 사용자의 요구를 정확하게 반영하기 힘듦 각 단계를 진행하는 중에 주기적으로 요구사항을 조율할 수 있는 체계적인 방법이 없으며 사용자들은 시스템이 동작되는 것을 보기 전에 자신이 원하는 것을 정확히 알지 못함 지속적으로 변화하는 요구사항을 적절히 처리할 수 없음 폭포 구현 프로세스는 하나의 단계를 완결하고 다음 단계로 진행하는 방식이기 때문에 요구사항 단계를 지나 새롭게 추가되는 요구사항을 반영하려면 프로젝트 일정에 상당한 부담을 주게 됨 개발된 소프트웨어 모듈들이 잘 조합되지 않을 수 있음 개발자들이 각자 개발한 모듈들은 테스트 단계까지 가야 서로 연동시켜 볼 수 있는데 이러한 모듈 사이의 인터페이스에 문제가 발생할 수 있음 대부분의 중대한 시스템 결점은 프로젝트 막바지에 발견되며 이를 처리하는 것은 매우 힘든 작업이 됨 품질 저하 추가적인 요구사항을 반영하기에 절대적으로 시간이 부족하기 때문에 버전에 따라 산출물간의 관계와 정보를 체계적이고 독립적으로 관리하기 힘듦 이에 따라, 유지보수에 큰 부담을 주며 반영시킨 요구사항에 대한 프로그램의 품질 역시 떨어지게 됨

다. 애자일 방법론과 폭포수 개발 방법론(전통적) 차이

구분 Agile 방법론 기존(폭포수) 방법론 요구사항 관리 지속적인 요구사항 개발 및 변경 수용 초기 요구사항 수집 및 엄격한 변경관리 계획수립 두 단계 계획(잦은 계획수립 및 갱신), 경험기반 프로세스 상세한 계획수립(up-front), 계획기반 프로세스 설계 적시(just-time) 설계 상세한 사전(up-front) 설계 문서화 경량(Lightweight) 프로세스 및 문서화보다 코드를 강조 중량(Heavyweight) 프로세스 및 상세한 문서화 강조 역할 전체 팀(Whole team) 워크 중요 엄격한 역할 분리(기능적 역할 분담)

라. 등장배경 1) S/W 개발 환경 변화 : 요구 사양 다양, SDLC 주기가 짧아짐, Time to Market 2) 기존 개발 방법론의 한계 - 문서 및 절차 위주의 방법론은 변화에 신속 대응 어려움 - 변화에 빠르게 적응하고 효율적으로 개발할 수 있는 방법론 필요 마. 특징

구분 설명 가변적 요구 대응 Predictive 하기 보다는 Adaptive 한 방식임 고객 만족 - 개발 후반부라도 요구사항의 변화 적극 수용 - 고객의 요구 사항 신속 대응 : S/W 배포 일정이 짧음 개발자 동기 부여 - 개발자에게 적합한 개발 환경 구성 - 개발자가 책임을 완수할 것으로 신뢰 PM의 역할 변화 - 프로젝트 관리자에서 촉진자로 변경 - 프로젝트 계획수립 및 통제의 책임이 팀원에게 이양 Sweet Spots - 한 작업실에 5~8명의 작업자 - Key User 상수 : 개발자와 사용자 간 중계역할, 신속한 피드백 가능 적용 범위 중소형 아키텍처 설계, 프로토타이핑에 적합

바. 종류

구분 설명 특징 SCRUM (OMG) 팀 기반 스프린트(30일) 단위 반복 개발, Scrum 활용 계획 수립 Iteration Planning, Tracking Process 중점, 대규모 적용 가능 팀 구성원 활동에 초점 XP eXtreme Programming 1~3주간의 Iteration 제안(User Story 단위)4대가치, 12항목 실천 사항(Practice) 제시, 테스트 강조 가장 주목 관리 관점 결여 DSDM Dynamic System Development MethodRAD 확장, 3단계 사이클 (기능모델→설계/구현→수행) 제시 2~6주 Timeboxed Cycle,방법론 지원 전담 조직 운영 영국 중심 FDD Feature Driven Development 5단계 (전체모델개발→Feature List 작성→계획→설계→구현) 개발자를 Chief Programmer(멘토)/Class Owner(코딩) 분류 짧은 반복(2주) 대규모 적용 Crystal Family 프로젝트 다양성(참여자 수, 에러 결과)에 따른 다양한 방법론(CLEAR/YELLOW/ORANGE/RED) 제시, 숙련도 낮은 개발자에 적합, Iteration Review에 많은 비중(스스로 문제점 파악, 해결) XP에 비해 생산성이 낮음 ASD Adaptive SW Development Adaptive 개발의 중요성과 결과를 조직적/경영적 측면 제시. 멤버들의 창조적 해답 중요시하여 의사소통 독려 강조 세부 Practice 없음

애자일 방법론 가. 익스트림(XP) 프로그래밍 나. SCRUM
애자일(Agile) 선언(개변동고)

전통적인 개발 애자일 개발 프로세스 및 도구 개인 및 상호작용 계획준수 변화대응 다량의 문서화 동작하는 소프트웨어 계약협상 고객협력

애자일 도입시 고려사항 가. 조직에 정착시키기 위해서는 조직 개발 문화의 근본적인 변화가 필요 나. 고객이 애자일에 대한 이해가 낮고 계약이 주도하는 SI 프로젝트의 경우 활용에 제약사항이 존재 다. SW관련 제품 개발, IT융합분야 SW개발, 스마트폰 애플리케이션 개발 등의 분야에 최적 라. 발주기관이 짧은 주기로 개발 결과물을 테스트할 수 있는 인력이나 역량을 갖춰야함 마. 짧은주기 단위로 개발 결과물을 만들어 내야 하기 때문에 개발자들의 업무 스트레스가 과중 될 수도 있다는 점도 해결해야 할 과제다.
애자일 방법론 장/단점

장점 단점 - 소규모나 타임 박스화된 서브 프로젝트나 반복주기에 적합(3~12주) - 사용자나 개발자가 정확한 요구사항 도출이 힘들 때 적합 - 대규모의 프로젝트보다는 기업 내 단위시스템에 적합 - 방법론으로 적용하기에는 프로세스 정립의 부족 - 대형 프로젝트에 적용이 어려움

익스트림(XP, eXtreme Programming) 프로그래밍 가. 철학

철학 내용 의사소통 고객과 개발자, 관리자들 사이에 밀접한 관계를 유지하면서 원하는 요구들을 피드백 단순성 설계를 단순하고 명확하도록 유지하고 가능한 작은 시스템을 짧은 사이클로 반복 피드백 고객의 피드백을 중요하게 생각함 용기 가능한 빨리 변경된 사항을 반영하여 고객에게 인도한다는 목표 아래 요구사항 및 기술 변경에 용감하게 대처

나. 12가지 실천사항

실천사항 내용 계획 세우기 (Simple Plan) 우선순위와 기술사항을 고려하여 범위를 결정 고객이 요구하는 비즈니스 가치를 정의하고 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지 알려줌 작은 릴리즈 짧은 사이클로 작은 릴리즈를 반복하여 개발 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 함 메타포 시스템 전체에 대하여 은유적인 접근 문장형태로 시스템 아키텍처 기술, 고객과 개발자간의 의사소통 언어 단순한 설계 (Simple Design) 최대한 설계를 단순하게 유지 가장 단순하며 정확히 작동하는 Design 테스트 기반 개발 (Test Driven Development) 개발과 동시에 단위 테스팅을 병행(지속적인 테스팅) 테스트 주도(TDD), 테스트를 통한 고객검증, 승인 리팩토링 코드의 품질을 지속적으로 개선 페어 프로그래밍 가장 좋은 구현 방법과 전략을 고민 두명이 한프로그램 개발(오류감소, 생산성 향상) 코드를 공유 누구나 코드를 수정하고 집단적인 소유로 여김 모든 코드는 모든 개발자에게 있으며, 이는 팀을 최상의 속도로 움직이게 하며, 변경이 필요할 때에도 지연을 줄임 지속적인 통합 (Continuous Integration) 개발한 것을 즉시에 또는 매일 통합, 빌드 지속적인 통합으로 개발의 불일치 최소화 40시간 작업 초과근무를 줄이고 계획적으로 작업 피곤한 개발자가 실수를 더 많이 함 현장 고객 (On-Site Customer) 고객이 개발 사이트에 상주하며 참여 고객의 팀 합류, 의사결정 지원 코딩 표준 표준에 맞추어 코딩 효과적인 공동작업을 위해서는 모든 코드에 대한 코딩 표준을 정의

다. 프로세스

프로세스 설명 계획수립 요구사항은 릴리스에 포함될 스토리 카드와 스토리에 기록되고, 가용 시간에 상대적인 우선순위를 결정 설계 복잡한 표현보다는 간단한 설계를 선호 코딩 핵심 개념중 하나로 두 사람이 작업을 같이 하는 Pair programming이 있다

XP 스토리 카드 가. 사용자 스토리
익스트림 프로그래밍에서 주된 개발 결과물
요구를 높은 수준으로 정의한 것으로 개발하는데 드는 노력을 예측할 수 있는 정보
사용자와 커뮤니케이션 하는데 필요한 참고 자료 나. 사용자 스토리 규모
2명의 개발자가 한 번의 개발 사이클로 완성될 수 있는 규모
1주 이내의 작업으로 완성될 수 있는 규모
예

학생이 월 정기 승차권을 온라인으로 구입 정기 승차권을 신용카드로 지불 교수가 학생의 성적을 입력 학생이 성적 증명서를 신청 학생이 이번 학기 신청한 강의 시간표를 출력 성적증명서는 표준 브라우저에 온라인으로 준비

XP에서의 요구분석, User Story의 개념 가. XP의 User Story의 정의
개발자와 사용자의 커뮤니케이션과 정확한 이해와 확인을 지원하는 XP의 실천사항으로 사용자 요구가 정리된 문서
요구사항 문서와 유사하나 사용자의 요구(needs)에 초점을 맞추고 있으며, 특정한 기술, 알고리즘, GUI레이아웃을 언급하기 보다는 사용자의 요구와 User Story로부터 사용자가 얻을 수 있는 이점 위주로 작성되어야 함
고객의 요구사항을 “문서화”하기보다는 “표현”하기 위한 것
사용자 스토리는 문서화 보다는 대화를 강조
사용자 스토리는 반복적 개발에 효과적으로 사용
요구사항 문서 또는 유즈케이스를 대신함 나. User Story의 장점
구두 의사소통, 이해용이, 계획수립에 적합한 크기, 반복개발에 효과적, 세부사항은 추후고려, 참여적 설계를 유도, 암묵적 지식을 구축 다. User Story의 3C

구분 설명 Card(카드) - 스토리는 전통적으로 인덱스카드에 작성된다 - 고객(제품 소유자)에 의해 작성된다 - 카드에는 추정치 또는 메모 같은것도 첨부될 수 있다 Conversation(대화) - 스토리에 들어있는 세부사항은 사용자와의 대화를 통해 도출된다 Confirmation(확인) - 테스트는 스토리가 정확히 개발(코딩) 되었는지를 확인한다

‘카드’는 스토리의 본문을 담고 있지만, 세부사항은 ‘대화’를 통해 결정되며, 구현을 ‘확인’하기 위한 테스트를 포함
User Story의 구성과 프로세스 가. User Story의 구성
서술 형태로 기록됨
대화를 통해 세부사항 구체화
테스트를 통해 스토리 완료 여부를 판단함 나. User Story의 3요소
Scope : 사용자에 의해 작성 후 결정되며, 개발자와의 대화를 통해 범위가 확정됨
Importance : 범위산정이 중요성도 사용자에 의해 결정됨
Estimation : 개발자의 의해 산정되며, 1~3주 내외 다. 사용자 스토리 예
“사용자는 자기가 작성한 글을 사이트에 등록할 수 있다.”
“사용자는 도서 정보를 조회할 수 있다.”
“사용자는 구매하고 싶은 도서를 여러개 선택할 수 있다.” 라. XP Process와 Scrum Process의 요구사항

구분 XP Process Scrum Process 요구사항정의 유저스토리(User Story) Product Backlog 주기 주기(1 ~ 3 weeks) Sprint(30 days) 반복개발계획 릴리즈계획 Sprint Planning Meeting 작업내용 과제(Task) * 스파이크솔루션 Sprint Backlog

Backlog Items

User Story의 작성 가. XP의 요구사항 분석, User Story 작성
사용자에게 가치를 평가 받을 수 있도록 기능을 표현
스토리가 큰 것 보다는 스토리가 많은 것이 좋음
가능한 짧게 작성하며, 부족한 부분은 스토리카드 뒷장에 Acceptance Test의 형태로 표시 나. User Story의 절차

주요절차 설명 1) 스토리작성 - 작성규칙 (I)ndependent : 스토리간 의존관계가 없어야 (N)egotiable : 고객과 개발 팀간의 대화가 가능해야 (V)aluable : 고객에게 가치가 있어야 (E)stimatable : 측정 가능해야 (S)mall : 가능한 적절하게 작은 단위로 작성되어야 (T)estable : 스토리가 성공적으로 개발되었다고 말할 수 있어야 함 2) 사용자 역할 모델링 - 사용자의 역할 정의 - 시스템의 역할 정의(상황에 따라, 사람이 아닌 것에 대한 역할이 필요할 때가 있음) 3) 스토리 수집하기 - 사용자 인터뷰, 설문, 관찰, 스토리 작성 워크샵 4) 사용자 스토리 추정 - 개발기간 및 난이도를 추정 - 플래닝 포커(델파이 기법 응용) - 스토리 포인트 산정 - 삼각 산정(작은 스토리와 큰 스토리와 비교함으로써 점수를 부여) 5)릴리즈/이터레이션 계획 - 언제 릴리즈 할 것인가? - 각 스토리의 우선순위는 어떻게 되는가?

릴리즈는 하나 이상의 이터레이션으로 구성
스토리에 우선순위를 매기는 것(우선순위를 매기는 방법이나 기법이 필요)
할당된 스토리 점수의 합은 팀 전체의 속도(Velocity) 산정치를 넘기지 말아야 함
좋은 User Story의 특징 및 고려사항 가. 좋은 사용자 스토리의 여섯 가지 특성
독립적
협상 가능
사용자 및 고객에게 가치가 있음
추정 가능
작음
테스트 가능 나. 주요 고려사항
스토리 카드는 고객이 작성함. 그 이유는 요구하는 기능에 대해 고객팀이 가장 잘 설명할 수 있으며, 나중에 개발자와 함께 세부사항에 대해 논의하고 스토리의 우선순위를 결정할 수 있어야 하기 때문임
스토리는 조직에 가져올 가치를 토대로 우선순위를 매김
사용자 스토리는 협상 가능해야 함. 스토리는 계약서나 요구사항 명세서처럼 꼭 구현한다고 기록된 것이 아니며, 스토리는 기능에 대한 짧은 설명일 뿐 세부사항은 고객과 개발팀이 대화를 통해 협상해야 함
필요한 모든 세부사항까지 포함할 필요는 없음. 뒷면에는 테스트할 항목을 기록해두는 것도 좋음
모든 스토리는 사용자에게 가치가 평가되어야 한다고 말할 수 있지만, 소프트웨어를 직접 사용하는 사용자와 소프트웨어를 구매하는 구매자가 다를 수 있다는 사실도 염두에 두어야 함
사용자 스토리는 고객이나 사용자에게 제공하는 이점이 드러나도록 작성

XP 페어 프로그래밍(Pair Programming) 가. 정의
두 명이 한 조가 되어 같은 컴퓨터를 사용하면서 개발에 참여하는 것
한 사람이 클래스를 코딩할 때 다른 한 사람은 그 클래스를 어떻게 테스트할 것인지 궁리
즉, 한 사람이 작업하고 있을때 다른 사람은 가이드 역할 나. 장/단점

분류 내용 장점 혼자서 하는 것보다 원리에 충실 둘이서 하면 일에 더욱 몰입하기 때문에 더 좋은 설계와 코드를 작성 단점 실력이 뛰어난 엔지니어가 초보 프로그래머와 같이 일하는 것에 실증이 날 수 있음 엔지니어 대부분 혼자 일하기를 좋아하며 페어로 일하는 것이 부담 될 수도 있음 생산성이 얼마인지 확인하기가 곤란함

다. Pair Programming의 구성요소

구성요소 내용 비고 Driver 코딩 표준에 따라서 코드를 작성하는 프로그래머 Coder Partner Driver에게 전략과 일여부 확인, 모든 것을 상기시켜주는 역할을 하는 Watcher or Observer Support

Driver와 Partner는 상호 보완적인 역할을 하며, 역할 Change로 코드와 시스템에 대한 이해가 높아짐
상호간 알고리즘, 프로그램에 대한 지속적 질문/응답을 통한 품질향상을 도모하고 Support 역할을 수행 라. Pair Programing의 7가지 효과 가. Pair Pressure : 정해진 시간 동안 할당된 일을 완성 하도록 입력 나. Pair Negotiation : 알고리즘이나 프로그램의 구조를 둘이 같이 협의 다. Pair Courage : 이전에 혼자 할 수 없었던 위험한 조치를 둘이 같이 협의 라. Pair Reviews : 혼자 짜는 프로그램을 동시 리뷰, 기존의 리뷰 방식보다 에러를 조기에 발견 마. Pair Debugging : 서로간의 대화를 통해 에러의 원인을 효과적으로 찾음 바. Pair Learning : 번갈아 가면서 프로그래밍을 하며 그것을 상대방이 관찰하고 대화하기 때문에 서로의 지식과 행동을 자연스럽게 배울 수 있음 사. Pair Trust : Pair를 이룬 개발자들은 서로를 신뢰해야함, 그렇지 않으면 좋은 결과를 얻을 수 없음
생명주기 가. 생명주기 핵심은 반복적인 방법(사용자와 상의하여 스토리를 기초로 우선순위를 정하고 이에 따라 여러개발 사이클에 걸쳐 소프트웨어를 출시) 나. 생명주기 프로세스
XP에서는 요구사항을 User Story로 작성하고, 작성된 User Story를 활용하여 릴리즈 계획을 수립하고, 승인 테스트를 위한 테스트시나리오 기능도 제공
처음 작업은 사용자 스토리 작성과 릴리즈 계획
주기(반복 계획) : 반복할 시기 동안 구현할 스토리를 분할하고 할당
승인 테스트 : 인수를 위한 테스트를 준비하고 통합되자마자 바로 테스트
스파이크 : 핵심 프로그램 모듈

CI(Continuous Integration : 지속적인 통합) 개요 가. CI(Continuous Integration)의 정의
팀 구성원들이 작업한 것을 자주 통합하는 소프트웨어 개발 실천방법 나. CI 가치 1) 소프트웨어 위험요소 감소
결함을 조기 발견
소프트웨어 건강상태 측정이 가능
가정의 감소 2) 반복적인 프로세스 감소 3) 언제든 배포 가능한 소프트웨어를 생성 4) 프로젝트 가시성 향상
빌드 상태, 품질 매트릭 제공 5) 개발팀이 소프트웨어 제품에 대해 보다 큰 자신감을 갖게 해줌
지속적인 통합과정 가. 기능관리 나. 단위 테스트(JUnit, NUnit) 다. 소스코드 버전관리(CVS, Subversion) 라. 빌드 스크립트(ANT, Rake) 마. 지속적인 빌드 바. 버그/이슈 관리(Bugzilla)
소프트웨어 위험요소들과 자동화 프로세스

소프트웨어 위험요소 자동화 프로세스 배포 가능한 소프트웨어 부재 - 빌드 실패 - DB 동기화 실패 - 배포 실패 소스 컴파일 DB 스크립트 테스트 릴리즈 뒤늦은 결함 발견 - 회귀테스트 부재 - 테스트 적용범위 부재 테스트 테스트 적용범위 측정 프로젝트 가시성 부재 - 자동화 피드백 메커니즘 부재 - 소프트웨어 시각화 역량 부재 통합결과 피드백 UML 다이어그램 생성 저품질 소프트웨어 - 코딩표준 비준수 코드 - 설계지침 비준수 코드 - 중복 코드 - 복잡한 코드 코딩표준 준수 검사 설계지침 준수 검사 중복코드 검사 코드복잡도 검사

저품질 소프트웨어 위험요소 검사 가. 코딩표준 검사
자동화 Tools : PMD, Checkstyle 나. 설계지침 검사
객체들 사이에 오고 나가는 관계개수를 세어 EC(Effect Coupling), AC(Afferent Coupling)를 측정
불안정성(Instability) = EC/(EC+AC)=>0이면 안정, 1이면 불안정
자동화 Tools : JDepend 다. 중복코드 검사
버그를 발견/보고/분석/수정하는 비용이 배로 증가
다른 버그는 없는지 확신 못함(중복코드를 아직 다 발견 못한 것일 수 있음)
추가작성 코드까지 테스트하는 비용이 증가 라. 코드 복잡도 검사 1) CCN(Cyclomatic Complexity Number, 순환복잡도 수) : 메서드 안에 있는 별개의 경로수
일반적으로 CCN이 10보다 크면 결함발생 위험이 크다
CCN 만큼 테스트 케이스가 있어야함

Test 주도 개발 방법 TDD의 개요 가. TDD(Test Driven Development)의 정의
요구사항 수집이나 모델링을 수행하기 전에 테스트 케이스를 먼저 작성하는 방법
기능위주의 테스트 설계후 테스트를 실시하고 코딩 및 리팩토링을 통해 코드를 진화해나가는 반복적인 테스트 주도 agile 개발방법의 practice
테스트 작성으로 요구사항 검증 및 설계의 고도화 추구하며 짧은 주기의 Life Cycle을 반복하는 테스트
설계-피드백 중심의 방법론
작성해야하는 프로그램에 대한 테스트를 먼저 작성하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성
테스트도 그 자체로 하나의 프로그램이며 프로그램의 요구사항을 반영할 수 있게 만듬
예제코드 => 두 수를 더하는 add 함수를 만들어야 한다면 add 함수부터 만드는 것이 아니라 다음과 같은 testAdd 함수를 먼저 만듬

int testAdd() { assert 5 + 4 == add(5, 4) assert -4 + 9 == add(-4, 9) }

=> 이 테스트를 통과하도록 add 함수를 만듬, 만약 testAdd를 실행했는데 add 함수에 문제가 있으면 assert에서 에러가 발생할 것이다. 테스트를 통과하면 add 함수는 5 + 4와 -4 + 9를 정확하게 계산해낸다는 것을 보증할 수 있다. 이처럼 테스트에 요구사항이 제대로 동작함을 입증할 수 있는 코드를 작성하고 이 테스트를 만족하는 실제 프로그램을 써나가는 것 나. TDD의 특성 1) Design for Testability : 소스코드의 의존성 감소, 독립적 테스트가 가능한 설계구조 2) 테스트 커버리지 확보 : 단위 테스트를 통한 테스트 커버리지 유지, 디버깅 시간 감소 3) 견고성 보장 : 발생 가능오류에 대한 조기 탐지가능 4) 기능에 집중 : 기능위주의 테스트 작성으로 해당 기능의 견고성이 증가함 5) clean code that works : 작동하는 깔끔한 코드지향 6) 예측 가능한 개발방법 : 끊임없이 발행할 버그관리, 종료 시점의 예측 7) 반복(iteration)을 통한 코드와 설계의 진화 2. TDD 수행 프로세스와 수행 원칙 가. TDD 수행 프로세스

짧은 구현, 반복을 통한 개발을 위해 테스트 사이의 간격 조정, 체크인후 해당 모듈에 대한 요구기능 고도화
add a test -> make it pass -> make it right -> get feed back
테스트를 작성한다.
작성한 테스트를 통과할 수 있도록 가장 빠른 방법으로 코드를 작성한다. 이 과정에 중복된 코드를 만들어도 상관 없다.
테스트를 수행한다.
테스트를 통과하면 작성한 코드에서 중복을 제거한다. 아니면 2번으로 돌아간다.
테스트를 수행한다.
테스트를 통과하면 완성. 다음 테스트를 1번부터 시작한다. 실패하면 4로 돌아가서 디버깅한다.

나. TDD에서 사용하는 패턴

패턴 설명 빨간 막대 패턴 테스트 작성후 실행되지 않는 기 개발된 모듈 내부에 대한 검증 테스팅 패턴 테스트 모듈간의 적합성 및 성능, 견고함을 검증 초록 막대 패턴 코드가 테스트를 통과 하도록 신속하게 작동하는 코드 작성 xUnit 패턴 자동화된 테스트를 위한 프레임워크, 자기참조(self-reference) 디자인 패턴 검증된 해결책 설계 Template, Best Practice(생성, 구조, 행위)

패턴 활용 반복적 수행으로 결함 밀도를 충분히 감소시켜 품질보증가능 다. 수행원칙 1) 테스트 마다 한 가지만 검증 : 테스트가 직관적이고 구현에만 집중, 자동화된 테스트 2) 중복되는 테스트 코드 제거 : 새로운 설계결정을 한 번에 하나씩 도입, 중복제거 3) 소스구조와 동일하게 유지 : 구현 코드와 테스트 코드의 완전 분리를 위함 4) 소스의 의존성 최소화 : 코드의 복잡성을 낮추기 위해 설계패턴 등을 활용한 최적화 설계유도 라. TDD의 사이클(단위 테스트 중심)
Red Code : Failing test, 일부러 비정상적 결과를 내도록 테스트
Green Code : Passing test, 정상적 결과를 내도록 테스트
Refactoring : 품질향상을 위한 소스코드 정리작업, 단순작동보다 꾸준히 유지보수를 용이하게 함
엔터프라이즈 응용 시스템개발에 적용할 때 예상되는 장애요인 및 제거방안 가. 장애요인

구분 장애요소 설명 사용자요구 신속하고 빈번한 요구사항 변경 TDD의 장점인 실용적이고 고품질의 프로그램을 개발하기 위해서는 요구분석 및 요구사항 변경을 짧은 주기로 수용해야 한다. 그러나 이런 요구사항 변경은 과도한 테스트 케이스의 변경, 반복적인 소스코드의 변경으로 이어지게 됨 테스트설계 테스트 케이스의 독립성 확보의 어려움 테스트 케이스의 개발이 실제 코드 개발 이전에 하기 때문에 반복적인 소스코드의 변경에 대해서 테스트 케이스의 독립성의 확보가 어려워짐, 개발초기에 전체 커버리지를 포함하는 테스트 케이스의 도출 또한 필요한데 환경 변화에 대해서는 독립성을 유지하기 어려움 코드작성 UNIT테스트의 자동화 툴 지원 및 툴의 유연성 테스트 자동화는 TDD에서 필수조건임 테스트가 자동화 되어 있지 않으면 충분한 테스트 실행이 될 수 없어서 개발주기에 맞춰 진행하는데 장애가 발생됨. 개발언어별 UNIT테스트 도구의 지원이 어려울 수 있음 리팩토링 반복적인 회귀테스트 TDD에서 테스트는 주로 UNIT테스트에 기반함 빈번한 테스트 케이스 변경에 대해서는 자동화 룰이 유연하고 신속하게 지원할 수 없을 경우에는 반복되는 테스트를 효율적으로 수행 할 수 없게 됨. 따라서 자주 변경되는 테스트 케이스를 효율적으로 수용 할 수 있도록 지원되어야 함

나. 장애요인 제거 방안

측면 장애요인 제거 방안 방법론 측면 Test Case의 객관성, 실효성 확보가 어려움 테스트 개발방법 숙지, 인식변화 패턴(디자인, 초록막대, 빨강) 활용 요구사항 측면 추가적 요구사항, 지속적, 빈번한 요구사항 반영 요구 요구공학 활용(요구사항 명세도출, 분석, 명세, 검증), Baseline, 요구사항 추적표 리팩토링 측면 테스트 코드로 인한 문제점 발생, 테스트 코드 잔재 데이터 이주, 메서드 추출, 중복 코드 제거 회귀 테스트 활용 모듈간의 연관성 확인 사용자 참여 사용자(현업 담당자)의 능동적 참여 결여, 일정지연 agile 방법론(xp, scrum 등) 활용 고객은 개발팀의 구성원, 요구사항을 명확하게 전달할 수 있는 책임성 부여 산출물 개발자를 위한 산출물 위주(소스코드가 문서화) 기존 개발 방법론의 산출물 Tailoring 유지보수시 활용

단위 모듈 선적용후 단계적 확대적용 필요, 코드 추적성 확보
TDD 개발 활용방안 및 효과 가. 활용방안

측면 활용방안 상세화 되지 않은 시스템 PoC, prototyping에 활용, 점진적 개발로 요구사항 상세화, 기능 상세화 Pair Programming 선임자와 후임자가 pair로 코딩 테스트 설계 부분을 선임자가 후임자는 코딩 부분을 전담 유지보수 측면 alien code의 제거 및 구조개선을 위한 개선 프로젝트에 활용

나. 효과 1) 즐거운 프로그래밍 : 검증 받은 자신감 있는 코드 작성 2) Simplicity : Simple, clean, 안정성 있는 코드를 만들기 3) 프로그래밍 실력 향상 : 가장 최적화된 디자인 설계가 가능 해지고, 테스트를 하기 위한 설계 기량 향상, 페어 프로그래밍 실시로 win-win 다. 고려사항 1) TDD개발방법 숙지 : 테스트 케이스의 이해와 익숙하기 전에는 일시적 생산성 저하가능 2) 자동화된 프로세스 : 테스트자동화와 형상관리, 버전관리 등 다른 관리 요소가 요구됨, 개발 통합 도구를 활용하여 커밋시 빌드/테스트 가능한 환경 구축 3) 방법론적 접근 : 시스템의 목적과 특성에 맞게 접근이 요구됨 5. TDD의 개발주기 및 절차 가. TDD의 개발주기

테스트 주도 개발은 주로 단위 테스트에 기반하며 기존의 테스트 기법과 가장 큰 차이점은 테스트의 개발을 실제 코드 이전에 실시 나. 테스트 주도 개발의 절차

구분 내용 테스트 케이스 추가 단위 프로그램 보다 테스트 프로그램을 먼저 작성 코드 작성 테스트에 만족하는 모듈을 고려하여 코드 작성 테스트 수행 작성된 코드를 테스트하여 성공시 다음 테스트 케이스 작성, 실패시 코드 수정 코드 수정 수정된 코드를 다시 테스트 수행 후 리팩토링 여부를 거쳐 코드 완성 리팩토링, 중복 제거 테스트에 성공한 코드는 계속적인 리팩토링 및 중복 코드 제거

TDD 개발의 장점 및 제안 가. 장점
테스트가 먼저 작성되어 프로그램 작성 즉시 테스트가 가능하고 테스트 영역을 프로그램의 100% 커버 가능하여 프로그램 오류를 줄이고 코드의 품질 향상가능
프로그램의 개발과정이 유연하고 실용적이며 높은 품질의 코드 개발 가능
프로그램 개발 주기가 짧고 요구사항을 즉각적으로 적용하는 부분에 효과적
현재 작성중인 테스트 케이스와 관련된 코드에 집중(한번에 한가지 테스트 케이스를 처리)
테스트 케이스 단위로 개발 일정을 수립가능(미세반복 (Micro-Iteration))
정확히 원하는 기능을 수행하는 코드를 작성할 수 있음(인터페이스에 주목하기 때문)
회귀 테스트에 유리
불필요한 코드를 작성하지 않게 됨 나. 제안
리팩토링을 통해 실행하는 부분을 지속적으로 개선해나감으로 요구사항이 없다 해도 리팩토링의 결과를 확인하기 위해 지속적인 테스트가 이루어짐
리팩토링과 지속적인 테스트는 개발에 대한 부담으로 작용하여 테스트 주도 개발을 어렵게 하는 원인임
테스트 주도 개발에서 개발자의 부담을 줄이기 위하여 전문적인 툴 필요
TDD로 개발시 단위 테스트에서 작성하지 말아야 할것과 해야 할것 가. TDD로 개발시 단위 테스트에서 작성하지 말아야 할것

구분 설명 소소한 코드까지 테스트하지 않음 단지 속성만을 가지며 동작은 수행하지 않는 간단한 객체에 대해 단위 테스트를 수행하는 것은 무의미 서드파티 모듈에 대해 테스트하지 않음 .NET 프레임워크 자체나 서드파티 API들을 테스트하지 않음

나. TDD로 개발시 단위 테스트에서 작성해야 할것

구분 설명 적정한 추상화 수준에서 테스트 수행 애플리케이션의 실행을 방해할 수 있는 로직의 전체적인 위험을 줄이기위한 것이므로 작성하는 테스트 코드가 소프트웨어를 구성하는 고수준의 추상화된 모듈을 대상으로 테스트 진행 경계 조건에 대한 테스트 비즈니스에 민감한 경우시 다양한 경계 조건에 대해 테스트 진행

TDD로 개발시 유용한 단위 테스트 작성방법

구분 설명 테스트를 빠르게 실행 테스트 코드가 느리게 동작하면 테스트의 활용도가 떨어짐 - 가상객체를 이용하여 시스템 외부로부터의 의존성을 제거 - 의존성을 가진 인터페이스에 대해 가상객체를 사용하면 테스트 코드를 독립적으로 실행할 수 있으며, 항상 일관된 결과를 가져온다는 것을 보장 테스트는 반드시 자동화되어 실행 테스트 코드의 실행이 자동화되어 손쉽게 실행할 수 있다면 개발자들이 코드를 업데이트할 때 도움이 됨 테스트 원자성 테스트 코드를 몇 번을 실행하든 항상 같은 결과를 얻음 항상 일관된 매개변수를 이용하여 테스트 코드를 몇 번이라도 실행할 수 있어야 함 제어할 수 없는 시간이나 날짜, 데이터베이스의 상태 등을 이용하는 변수에 의존해서는 안됨 테스트는 명시적이며 가독성이 뛰어나야 함 테스트 코드에 의미 있고 서술적인 이름을 부여하여 다른 개발자들이 해당 테스트가 어떤 동작을 검증하기 위한 것인지를 즉시 이해해야 함 테스트 독립적 테스트 코드는 반드시 다른 테스트 코드로 부터 독립적이어야 하며 다른 테스트 코드에 의존적이어서는 안됨 테스트를 손쉽게 설정 테스트 코드는 직관적이어야 하며 손쉽게 설정이 가능해야 함

실용주의 개발 방법론 SCRUM의 개요 가. Agile기법 SCRUM의 정의
SCRUM은 1986년 일본에서 개발 환경을 최대한으로 이용하고 조직의 고정비를 줄이며 반복적인 프로토타입을 기반으로 시장 수요에 가깝게 동기화 하는 세트
비즈니스 요구사항을 만족시키는 소프트웨어를 개발하는데 초점을 맞추기 위해 복잡함을 제거하는 관리 및 제어 프로세스 나. SCRUM의 특징

특징 설명 협업중심 스크럼은 주로 팀 수준의 시안을 다루며, 효율적으로 팀원들이 협업 할 수 있는 환경을 제공 활동에 집중할 수 있게 하여 고품질의 제품을 생산할 수 있게 해 줌 사회공학 기법 프로젝트 이해관계자들 간의 협력을 촉진하여 관련자 성취감의 충족을 목적으로 하는 사회 공학적 기법 Sprint 수행 스프린트(Sprint)라는 통상 4~6주 정도의 잘 정의된 개발 주기를 가지며 개발 효율성을 극대화할 수 있는 환경 제공 Daily Meeting 8~10명 정도로 이루어진 SCRUM 팀은 매일 15분 정도의 회의를 통해 지난 업무나 앞으로의 계획된 일에 대한 리뷰 실시

SCRUM의 프로세스 및 스프린트 사이클 가. SCRUM의 프로세스

프로세스 설명 Product Backlog 시스템이 해결해야 하거나, 시스템이 포함되어야 할 기능, 특성과 기술에 대한 모든 기술 나열 요구되는 제품의 요구사항 우선순위 나열, 프로젝트가 진행 되면서 진화되고 변경 됨 Sprint Backlog 해당 스프린트 기간에 수행해야 하는 Task의 목록 통상 4~6주 정도(약 30일정도)의 잘 정의된 반복개발주기 동안 개발 가능한 기능의 목록을 제품 백로그에서 선택 sprint 각 스프린트 단계 종료시 새로운 기능이 추가되어 실행 가능 제품이 인도되어야 함 Daily Scrum 매일 약 15분 정도의 짧은 회의 관리자는 진척사항 검토, 정상적 종료를 방해하는 위험의 확인, 팀의 진척 정도 확인

나. SCRUM의 Sprint Cycle

SCRUM 기법의 프로젝트 팀에게 미치는 영향
스크럼은 구체적인 실천법을 모아둔 것이기 보다는 팀에게 가시성을 제공하는 프레임워크이며 가시성을 바탕으로 팀이 ‘관찰하고 적응하게’ 하는 메커니즘
스크럼은 제품 책임자와 팀이 효과적으로 일하는데 부정적 영향을 미치는 역기능이나 장애요인들을 드러내 문제 해결의 기회 부여
스크럼이 역기능을 드러내고 팀이 그것에 대응하기 위해 무언가를 하도록 하는 문제 해결 능력을 내양 하는 과정을 통해 팀이 두드러지게 효과를 볼 수 있음
분석된 조사결과에 따르면 스크럼을 통해 팀 생산성은 평균 36% 정도 향상 됨
SCRUM 방법론의 필요성 1) 기존 방법의 한계

항목 기존 방법론 Agile 대표적인 방법 Waterfall XP Task의 정의 Task 프로세스는 거의 정의 하지 않음 Task 관리의 전략과 수행 방법 기술 프로젝트 관리 관리가 용이 전체 스케줄에 대한 예측과 관리 어려움

2) 해결책 : 두 가지 접근 방법의 문제점을 상호 보완하여, 전체 프로세스는 기존의 전통 방법론을 따르고, 전체 프로세스의 각 단계를 Agile 방법론으로 보완하여, 실질적인 task 관리 방법론을 구축 필요 5. SCRUM의 구성 및 구성역할 가. SCRUM의 구성

구성 설명 Sprint 각 Iteration을 의미, 1 ~ 4주 정도의 기간 Sprint는 일종의 Time box의 개념을 가지며 한번 정해진 Sprint의 기간은 변경될 수 없다는 것을 전제 Product Backlog 대략적인 할일 목록 SRS(Software Requirement Specification)이나 TRS(Technical Requirement Specification)들에 해당하는 목록 Sprint Backlog 이번 Sprint에서 구체적으로 해야 할 일을 정의한 목록 리스트 Product Backlog 항목의 우선순위(Priority)를 통해서 선택됨 Daily Scrum Meeting 팀원들은 어제 한일과 오늘 한일에 대해서 간략하게 보고 기술적인 질의 사항에 대한 문의나, RISK 사항, 진행상황 등을 공유 매일 아침 팀원들은 10~20분 정도의 미팅 Review Sprint가 끝난 후에 팀은 프로젝트의 stakeholder(고객)에게 데모로 소개하고, Feed back을 받아서 다음 Product Backlog를 업데이트 Retrospective (회고) Scrum 방법론을 적용했을 때의 잘되었던 점과 잘못되었던 점을 토론하여 Scrum 운영 프로세스에 반영 나. SCRUM 구성의 역할

역할 설명 Product Owner (제품 책임자 1명) 요구사항을 정의하고, Product Backlog를 업데이트 하는 역할 Product Backlog내의 Item에 대한 우선순위를 정하고, 정해진 구현 기간 내에 프로젝트 팀의 ROI를 극대화 하는 책임 직접 Sprint에는 참여하지 않고, Sprint전에 Backlog의 업데이트 후, Spring review에 구현 내용이 요구사항에 맞춰서 적절하게 구현되었는지 확인하는 작업에만 참여 Scrum Team (스크럼 팀 7±2명) Product Backlog의 내용에 따라 Sprint에서 구현하는 역할 Scrum Master (스크럼 마스터 1명) 3자의 입장에서 Team과 Product Owner가 Scrum 방법론을 제대로 수행할 수 있도록 돕는 역할

제품 백로그(Product Backlog)의 정의
스크럼(Scrum) 개발 방법론에서 우선순위가 매겨진 요구사항 목록 및 스크럼의 핵심
Product Backlog의 주요항목

주요항목 내용 ID 자동으로 매겨지는 고유 식별자, 이름을 바꾸더라도 스토리 추적가능 이름 스토리를 설명하는 짧은 이름, 이름을 명확하게 붙여 개발자와 제품 책임자가 이름만 보고 스토리 내용을 파악, 다른 스토리와 구분 중요도 제품 책임자가 생각하는 스토리의 중요도, 숫자로 나타내며 숫자가 클수록 중요 최초 추정치 다른 스토리와 비교하여 이 스토리를 구현하는데 상대적으로 얼마나 많은 노력이 필요한지에 대한 팀의 최초 추정치 추정치의 단위는 스토리 점수이며 대개 이상적인 맨데이(man-day)에 해당 데모 방법 스프린트 데모에서 이 스토리를 어떤 형태로 데모할 것인지에 대한 상위 수준 묘사(간단한 테스트 명세서) 참고 그 밖의 다른 정보나 설명, 참고사항 등을 간단하게 기록

Product Backlog의 예시

ID 이름 중요도 추정치 데모방식 참고 1 입금 30 5 로그인, 입금페이지 열기, 10유로 입금, 잔액조회 페이지로 이동, 잔액이 10 유로로 증가했는지 확인 UML 시퀀스 다이어그램 필요, 지금은 암호화를 고려하지 않아도 됨 2 거래내역 조회 10 8 로그인, 거래내역조회 클릭, 입금실행, 거래내역으로 조회로 다시 이동, 입금내역확인 조회 내역이 많은 경우 페이징 처리

SCRUM과 XP의 비교

구분 SCRUM XP 형태 Agile Management 방법론 관리자 주도가 바람직 Agile Engineering 방법론 개발자 주도가 바람직 내용 - 개발 프로세스를 위한 프레임워크 - 관리 및 조직적 실천법에 집중 - 특정한 엔지니어링 방법을 포함하지 않음 - 엔지니어링 방법에 초점을 맞춤 - 프로그램 실천법에 집중 - 개발 프로세스의 핵심 프레임워크는 포함하지 않음 개발주기 4~6주 1~2주 요구사항 변경 - Sprint 내에서 요구사항 변경을 수용하지 않음 - 변화를 최대한 빨리 발견하고 처리하는 관점에서 접근 - 리팩토링을 통하여 요구사항 변경을 수용 - 요구사항 변경은 당연히 발생하는 것으로 인정 개발 우선순위 결정 주체 Product Owner가 아닌 Team이 개발 우선순위 결정 Customer가 개발 우선순위를 결정 공통점 Agile 방법론으로서 짧은 개발 주기로 반복 개발 상호보완적 관계

SCRUM 적용 현황 및 적용 시 고려사항 가. SCRUM 적용 현황 1) 금융, 보험 등 보수적인 산업에 있는 기업과 Google, Yahoo, MS 등도 SCRUM을 선택 2) Agile 방법론을 실행하는 팀 중 약 50%가 Scrum을 사용하고, 20%가 Scrum을 XP 구성요소와 함께 사용하고, 12%가 XP만을 사용 나. SCRUM 프로젝트 적용 시 고려사항 1) 전체 프로젝트에 대한 큰 Mile Stone은 기존 개발방법론을 사용하고, SCRUM 방법론은 각 단계에 대한 Task를 위해서 사용 2) 어떤 전문화된 시스템이나 도구가 아니라, 팀이 최대한의 효율을 낼 수 있는 프로세스가 중요

구분 설명 스크럼을 바꾸려 하지 마라 스프린트 목표달성이 어렵다고 스프린트 기간을 늘리는 행동 - 팀원들이 목표를 선정하고 달성을 위해 배울수 있는 기회를 박탈함 관리자의 부적절한 개입 최소화 관리자로부터 명령을 받는다고 해당 프로젝트가 성공하는 것이 아님 해당 조직 스스로가 배우고 개선하여 자기조직화 시키는 것이 핵심임 책임감있고 신뢰기반의 의사소통 계획회의시부터 책임범위내의 목표설정 및 업무수행을 통한 신뢰 향상 절대 할 수 없는 일에 대한 목표설정 및 기간연장은 없다

다. 스크럼과 XP를 통한 대형 프로젝트 수행 - 역할을 기반으로 여러개의 스크럼팀을 분할하여 스크럼마스터가 PL의 역할을 수행 - PL과 고객은 팀의 Helper 역할을 수행하여 팀의 개발 진척을 돕는 형태의 조직으로 구성 - 스크럼팀간의 연계를 위해 스크럼 Board 및 Burndown Chart를 적극 활용하여 전체 프로젝트의 진척을 관리 - 스크럼팀간에는 유사한 스토리규모(스토리포인트)를 분배하여 전체적인 공정관리가 요구됨 - 스크럼을 수행하더라도 Engineering base과 함께 적용하여 고품질의 프로젝트 수행 및 제품 개발 기대 [참조] 1. Product Backlog와 Sprint Backlog의 비교

구분 Product Backlog Sprint Backlog 상세 수준 조금 상세함 매우 상세함 예측 단위 스토리 점수 시간 문서 소유권 Product Owner Team 수정 주기 매주 매일 기간 프로젝트 기간 내 Sprint 기간 내

SCRUM과XP의 용어 비교

SCRUM XP Product Owner Customer SCRUM Master XP Coach Team Team Sprint Iteration

제품백로그 스프린트 작업 지원자 초기 작업량 추적 날짜별 남은 작업량 1 2 3 4 5 6 장바구니 기능 데이터베이스 수정하기 김선미 5 2 3

웹 페이지 만들기(UI) 이상완 3 1 2 1 2

팀원들은 매일 스프린트 백로그에 자신들의 현재 작업을 완성하기 위한 남은 시간 추정치를 갱신함
모두가 갱신하고 나면 팀 전체의 남은 시간을 합하여 스프린트 소멸차트(Burndown)를 갱신함
스프린트 소멸차트는 앞으로 얼마나 작업량이 남았는지의 관점에서 진척도로를 보여줌
SCRUM 에서 사용되는 주요 개발도구 및 기법

구분 설명 TDD 사용 UI의 경우 진지하게 고려, 단순한 테스트 케이스는 제외 버그파티 탐색적 테스팅 기법등을 활용하여 고품질의 SW 생산을 위한 테스팅 수행 결함카드 스프린트 시작시마다 빈 결함카드 할당 및 주요결함에 대한 주기적 갱신 소통도구 메신저, 트위터, 전자메일등을 이용한 팀원들간의 소통창구 마련 Pair Programming 품질향상, 리팩토링을 위한 Pair Programming 수행 CI/ALM Daily Build, 지속적 통합을 위한 형상관리, 배포관리, 테스트 자동화 수행

서비스 지향 아키텍처(SOA, Service Oriented Architecture) 가. 정의
웹과 같은 네트워크상에서 사용할 수 있는 서비스를 사용하여 소프트웨어 애플리케이션을 구성할 수 있게 하는 아키텍처 스타일
소프트웨어 컴포넌트들 사이에 느슨한 결합을 허용함으로써 재사용을 쉽게 만듦
전통적인 프로그램 중심의 설계/개발 방식에서 비즈니스 프로세스 관점에서 재활용 가능한 단위로 서비스를 설계/개발하게 함으로써 특정 서비스의 변경이나 비즈니스 통합 시 효율적이고 빠른 대응이 가능
서비스를 조합함으로써 새로운 애플리케이션 서비스를 구현할 수 있는 통합 기술이자 아키텍처 모델
특정 기술이나 플랫폼에 종속적이지 않고 느슨한 결합 속성을 가지고 상호 연동이 가능 나. 장점
서비스 : 구현 기술에 관계없이 잘 정의된 인터페이스를 가진 소프트웨어 컴포넌트
서비스 인터페이스를 구현으로 분리(서비스를 사용하는 클라이언트는 그것이 어떻게 요구를 수행하는지에 관심이 없이 사용)
서비스는 내부 함축적이고 느슨하게 결합
서비스는 동적으로 발견
복합 서비스는 다른 서비스를 모아서 만듦 다. 특징
Reuse : 논리적 재사용 단위인 SOA Service Block 구성
Integration : 표준 interface(XML, SOAP, WSDL) 통한 통합
Agility : 서비스 단위 조립을 통한 민첩성 제공
반복된 개발비용을 줄이고 프로젝트 기간을 단축 라. 등장배경
소프트웨어 산업은 점점 복잡해지고 서로 연동되기 힘든 다양한 플랫폼 환경으로 구축되어 재사용성과 애플리케이션의 통합 및 비즈니스 환경 변화에 융통성과 민첩성이 어려워짐 다. SOA Find(발견)-Bind-Execute(등록) 패러다임
서비스 사용자 : 레지스트리를 이용하여 원하는 서비스를 찾음
서비스 제공자 : 서비스를 공개된 레지스트리에 등록
웹 서비스를 이용한 SOA 구현 가. 웹서비스(Web Service)의 정의
SOA를 구현하게 하는 표준 기반 통신 방식
SOAP, WSDL, UDDI 등의 표준 기술을 이용하여 네트워크에 연결된 다른 컴퓨터간의 개방형 분산 컴퓨팅을 지원하는 소프트웨어 및 기술
표준방식으로 분산 저장되어 있는 자원들을 공유하고 호환 가능하게 하는 인터넷 서비스
XML에 기반을 둔 플랫폼과 구현 언어에 독립적인 컴포넌트 기반의 분산 컴퓨팅
네트워크상에 있는 컴퓨터들이 상호운용 가능하도록 설계한 소프트웨어 시스템
상호운영성 : XML을 기반으로 한 표준 규격인 WSDL, SOAP, UDDI 때문에 가능 나. 웹서비스의 주요기능

주요기능 설명 정보시스템 통합 Issue 해결 웹 서비스를 사용하여 일괄된 통합 및 연계수행 Plug & Play 기능을 활용하여 신규 애플리케이션 추가 빠른 Time to Market 기업 파트너 간 쉽고 빠른 연계와 통합 가능, 비즈니스 적시성 및 서비스 품질 제공 SOA 지원 애플리케이션 환경에 관계없이 실행 및 상호 운영, 비즈니스 로직 단위의 프로세스 결합

다. 웹서비스의 특징

특징 설명 단순성 XML 기반으로 기존의 분산 컴퓨팅 모델에 비해 보다 단순하고 확장이 용이한 모델을 제공 상호운영성 교환 메시지를 포함한 모든 정보 표현에 있어 XML을 이용하여, 기존의 웹 환경위에 바로 구현 시스템 구조의 유연성 메인 프레임 또는 서버-클라이언트 방식과 달리 유연한 소프트웨어 구조를 통해 이질적인 데이터 표준을 유연하게 통합/운영 사용의 편리성 사용자는 소프트웨어를 설치한 후 자연스럽게 서비스를 제공받게 되며, 인터넷을 연결할 수 있는 유/무선 단말기를 통해 장소에 관계없는 접근이 가능 통합환경의 제공 이질적인 애플리케이션간의 통합 서비스를 제공받을 수 있고 새로운 시스템과의 통합도 자동적으로 이루어짐 비용 효율적 분산 시스템의 소프트웨어 간 통합을 자동화적으로 이행해줌으로써 IT개발 및 운영비용을 절감

라. SOA를 구현하는 사용된 기술

UDDI(Universal Description Discovery and Integration) : 플랫폼에 무관한 XML기반 레지스트리
WSDL(Web Service Description Language) : XML기반 서비스 정의 명세, 웹 서비스를 이용하여 어떻게 커뮤니케이션 하는지 나타냄, SOA(Service Oriented Architecture)의 일종인 XML 웹서비스에서 특정 서비스의 인터페이스를 정의하는데 사용되는 표준
SOAP(Simple Object Access Protocol) : 네트워크상에서 XML 기반의 메시지를 교환하기 위한 프로토콜
SOA를 이루는 계층 가. 개념도
가장 중요한 층은 서비스 층과 비즈니스 층 나. 표현 층
사용자 입장에서 매우 중요한 부분
JSP, JSF, Java 클라이언트 등으로 구축
MVC(Model View Control) 프레임워크 같이 다른 층에 대하여 느슨한 결합을 가짐
문제점 => JSP, Java 클라이언트, EJB, 웹 서비스 등 서로 다른 클라이언트 사이에 데이터 교환을 위한 바인딩이 표준화 되어 있지 않음 => 예 : 웹서비스나 EJB를 사용하여 구현한 서비스들이 데이터 교환하는 인터페이스가 각기 다름 다. 프로세스 층
비즈니스 프로세스를 설계하고 실행 시키는 BPEL(Business Process Execution Language) 제공
BPEL : 프로세스의 파트너에 대한 링크, 조작하는 변수, 관련되는 메시지, 오류처리, 문제 발생시 보충, 이벤트 처리 등에 대한 사항을 XML 형태로 기술 라. 서비스 층
서비스를 명세화 하는 방법
WSDL을 이용하여 입출력 메시지, 타입, 오퍼레이션을 정의 마. 비즈니스 층
레거시를 포함하여 EJB, Java 클래스 등 여러가지 방법으로 구성
SOA에서 재사용하는 단위 및 계층
SOA 구현위한 웹서비스 구성요소 역할 가. SOA 구현위한 UDDI, WSDL, SOAP 역할

구분 역할 UDDI 필요한 서비스를 찾을 수 있는 웹 서비스 레지스트리(서비스 등록, 검색) 웹 서비스와 비즈니스를 발행(publish)/검색(Find)하기 위한 기술적인 스펙 UDDI 데이터 범주 - white 페이지 : 회사에 대한 일반적인 정보(비즈니스 이름, 세부내용, 주소) - Yellow 페이지 : 회사나 서비스가 제공하는 분류된 데이터(표준 분류법을 토대로 산업별, 제품별, 지리적 코드별로 나눈 데이터) - Green 페이지 : 웹 서비스에 대한 기술적인 정보(외부 스펙을 가리키거나 웹 서비스 호출에 대한 주소) WSDL 웹 서비스를 표현하고 기술하는 언어(서비스 표현) 웹 서비스의 공개 인터페이스를 설명하기 위한 XML문법 공개 인터페이스 - 공개적으로 사용할 수 있는 기능들의 정보 - XML 메시지를 위한 데이터 타입 정보 - 사용된 전송 프로토콜에 관한 바인딩 정보 - 특정한 서비스 위치에 관한 주소 정보 WSDL은 XML 메시지 시스템에 꼭 필요한 것은 아니지만 SOAP 메시지를 기술하기 위한 빌트인 익스텐션(built in extensions)을 포함 SOAP 웹 서비스에서 사용되는 보편적이며 확장성 있는 메시지 프로토콜(데이터 통신 프로토콜) 분산 컴퓨터 환경에서 정보를 교환하기 XML기반 프로토콜

나. SOA위한 웹서비스 구성도

웹 서비스의 주요 구성요소 구현예제 가. SOAP 구성 및 코드 샘플
XML을 근간으로 헤더와 바디를 조합하는 디자인 패턴으로 설계
헤더는 선택사항으로 반복이나 보안 및 트랜잭션을 정보로 하는 메타정보를 정의
바디 부분은 주요한 정보 저장 영역

827635

나. WSDL 문서 구조 - 웹 서비스 기술언어 또는 기술된 정의 파일의 총칭으로 XML로 기술 - 서비스 제공 장소, 서비스 메시지 포맷, 프로토콜 등이 기술

웹지향아키텍처 WOA의 개요 가. WOA(Web Oriented Architecture)의 정의
웹의 아키텍처를 기반으로 전 세계적으로 연결된 하이퍼미디어를 통해 시스템과 사용자를 통합하는 SOA의 아키텍처 서브스타일
SOA를 구현하는 더 간단한 방법론 나. SOA와 WOA의 차이점
SOA : XML, SOAP, WSDL, UDDI 등 정교한 웹 표준에 맞춰 웹서비스 개발
WOA : 데이터 활용에 초점을 맞춰 누구나 손쉽게 가져다 쓸 수 있도록 최대한 간편하게 구현(ex : HTTP)
WOA 단점 : 대용량 기업 데이터 처리에 대해 검증이 되지 않았고 무엇보다 보안 기능이 약함
WOA의 활용성 가. 클라우드 플랫폼 기반으로 웹 애플리케이션을 개발해 배포하거나 메신저나 날씨, 지도 등 다른 웹서비스나 애플리케이션을 결합해 새로운 웹서비스 개발
SOA와 WOA 장∙단점 비교

구분 SOA(서비스지향아키텍처) WOA(웹지향아키텍처) 장점 언어, 플랫폼, 전송 중립 언어, 플랫폼 중립 분산컴퓨팅 환경 위한 디자인 SOAP보다 웹서비스 개발용이 웹서비스 표준으로 널리 사용 매시업(Mash-UP) 방식을 이용한 새 웹서비스 개발이 비교적 쉬움 다른 표준과의 통합, 확장성 우수 단점 WOA 대비 어렵고 무거움 보안, 정책, 안정적 메시지 전달을 지원하는 표준이 부족 개발 난이도가 높고 툴이 필수적

관심사의 분리(SRP)를 통한 개발 및 유지보수 향상방안, 관점지향 프로그래밍, AOP의 개요 가. AOP(Aspect Oriented Programming)의 정의
시스템의 기본적이고 대표적인 업무처리 기능을 나타내는 핵심관심사(core-concerns)와 여러개의 모듈에 걸쳐 산재되어 있는 사용자 인증, 로깅과 같은 횡단관심사(cross-concerns)를 구분함으로써 시스템 설계와 구현의 복잡성을 감소시키고 모듈화를 이루려는 패러다임
공통의 관심사항을 적용해서 발생가능한 의존관계의 복잡성과 코드 중복을 해소해주는 프로그래밍 기법
수정(modification)과 유지보수의 용이성을 향상시키기 위하여, 시스템이 제공하는 핵심적인 기능들로부터 공통의 횡단 관심사(crosscutting concern)를 추출하여 별도의 프로그램으로 작성한 후 핵심 기능 프로그램과 결합(weaving)하여 프로그램을 생성하는 방법 나. AOP의 필요성

나. AOP 탄생의 기반, 객체지향 설계 원칙 - OOP 의 의존관계에 따른 복잡성을 해결하기 위해 설계단계에서 준수해야할 원칙 - 재사용성 및 유지보수성 향상으로 모듈화를 통한 개발생산성 향상 기대 - SRP (단일책임의 원칙) 에 따라서 단일모듈에 여러가지 책임 (공통관심, 횡단관심) 을 공유하지 않음 - 횡단관심은 별도의 모듈로 분리하여 공유, 횡단관심의 변경시에도 핵심관심의 영향을 최소화 함 다. AOP의 등장배경

구분 설명 기능의 분산 (Scattering) OOP의 SRP원칙을 현실세계에서 지키기 어려움 그로 인해 객체지향으로 설계한 모듈에 보안이나 모니터링 기능이 분산해서 존재 코드의 혼란 (Trangling) 인프라스트럭처 서비스(Tracing, Logging, Monitoring 등)의 많은 요구로 인해 최초 OOP방식으로 작성된 코드가 지저분한 코드로 바뀌게 됨 OOP의 코드 유지 OOP에 충실한 모듈의 구현

라. AOP의 특징

특징 내용 중앙집중 여러 분산 함수의 중앙 집중 통제 단순 개발 절차 단순화 고유영역 개발자 자신만의 특정 기능 수행 영역 속도 빠른 개발 가능 비캡슐화 핵심 비즈니스영역 보다는 주변업무중심 공통모듈 해당 Aspect 이용 별도의 Aspect라는 구조를 이용

AOP의 구성도 및 구성요소 가. AOP의 구성도
횡단관심 모듈을 각각 독립된 모듈로 중복없이 작성하고 위빙을 통해 핵심관심 모듈과 결합시키기 때문에 서로 독립성을 가진 다차원 모듈을 작성
OOP를 대체하는 프로그래밍 기법이 아니라 OOP를 보완하는 기법으로서 기존의 OOP가 가지고 있었던 문제점, 즉 비즈니스 로직을 담당하는 소스코드 외에 로깅, 예외처리와 같은 부가 기능들이 애플리케이션 소스코드의 전체 영역에 걸쳐서 비슷한 패턴으로 산재되어 유지보수의 어려움을 발생시키는 것에 대한 해결책을 제공 나. AOP의 개념도
핵심과 횡단의 분리를 이루고 서로간에 weaving을 통해 구현
횡단관심을 핵심관심에서 분리하여 이를 Where, When 개념을 이용하여 Weaving 을 통해 삽입함 다. AOP의 동작원리
weaving을 통해 핵심관심 모듈의 사이에 필요한 횡단관심 코드가 동작 라. AOP의 구성요소(언제, 어디에, 무엇을, 어떻게 삽입할 것인가?)

구분 설명 advice(when) 언제 공통 관심기능을 핵심관심에 적용할지를 정의 ex) 메서드를 호출하기 전 (언제) ‘로깅을 시작한다’ (공통기능) 핵심관심 시스템이 추구하는 핵심 기능 및 가치 횡단관심 핵심관심에 공통적으로 적용되는 공통 모듈 조인포인트(JoinPoint) (where) 횡단관심 모듈 기능이 삽입되어 동작할 수 있는 실행 가능한 특정위치 Advice (공통관심) 를 적용 가능한 지점을 의미 포인트컷(PointCut) 어떤 클래스의 어느 조인포인트를 사용할 것인지를 결정하는 선택 기능 어드바이스(Advice) 각 조인포인트에 삽입되어져 동작할 수 있는 코드 위빙(Weaving) (HOW) 포인트 컷에 의해서 결정된 조인포인트에 지정된 어드바이스를 삽입하는 과정 Advice(공통관심)를 핵심관심에 적용하는 과정을 의미 관점(Aspect) (what) 포인트 컷(어디에서)과 어드바이스(무엇을 할 것인지)를 합쳐놓은 것 여러객체에 공통으로 적용가능한 공통 관심사항(Crosscutting Concern)

바. AOP에서의 3가지 주요 Weaving 방식

유형 설명 컴파일시 핵심로직을 구현한 소스 코드를 컴파일 할 때에 알맞은 위치에 공통코드를 삽입 - AspectJ 에서 주로 사용하는 방식으로 이를 도와주는 컴파일러나 IDE 가 제공됨 클래스로딩시 1. JVM 등에서 클래스 로딩시에 정보를 변경할 수 있는 에이전트를 제공 2. 에이전트가 로딩한 클래스의 바이너리 정보를 변경하여 알맞은 위치에 공통코드 삽입 - AspectJ 5 버전에서 컴파일 방식과 함께 클래스 로딩 방식을 지원 런타임시 프록시를 이용하여 핵심로직을 구현한 객체에 직접 접근하지 않고 프록시를 통해 접근함 프록시는 핵심로직을 실행하기 전 또는 후에 공통기능을 실행하는 방식 - 소스코드나 클래스정보 자체의 변경은 없으며 Sprint Framework 에서 주로 사용하는 방식

바. 요구사항 분석을 통한 관심 식별과정

요구사항 분석을 통한 핵심관심과 횡단관심의 식별 마. AOP와 OOP의 비교

항목 AOP OOP 목적 부문별 조립으로 생산성 제고 상속 및 재사용 통한 효율 제고 산출물 Aspect Class 관심사 공통로직(로깅, 보안, 트랜잭션) 업무로직 최적활용 업무적 중요 및 공통 모듈 CBD 사상적 근거, 교육 장점 환경 독립성, 횡단관심, 공통 적용 객체 재사용 단점 구현과 이해에 시간이 소요 객체별 독립성 유지 어려움

정적 AOP와 동적 AOP 가. 정적 AOP : 컴파일/링크 중에 관점이 삽입 나. 동적 AOP : 관점 모듈이 실행 중에 삽입되거나 변경되기 위해 사용
변경된 자바 가상 머신(JVM)을 사용하거나 바이트코드를 수정
포인트컷과 어드바이스 명세 파일을 수정함으로써 실행시간에 메소드를 교체
AOP를 이용한 SOA기반 프레임워크 및 구성요소 가. AOP를 이용한 SOA기반 프레임워크
SOA기반 애플리케이션의 지속적인 실행을 보장하기 위해 예외처리기를 관점 서비스로 분리하고 외부의 저장소에 저장
저장소는 동적으로 의미적 매칭을 사용하여 서비스를 검색하고, 관점 명세서에 서술된 관점 규칙에 따라 시스템적인 오류 상황에 대처 나. AOP를 이용한 SOA기반 프레임워크 구성요소

구성요소 설명 웹 서비스(WS) 에이전트 서비스의 핵심기능을 제공하는 에이전트 예외처리 기능과 같은 관점 기능은 관점 서비스로 독립되고 필요한 시점에 동적인 위빙 과정을 거쳐서 수행 서비스 에이전트 (service agent) 서비스 제공자로 부터 제공되며, 서비스를 실행하기 위한 기능적/비기능적 특징이 정의 되어 있는 서비스 명세 정보 XML 기반 관점 명세서에 저장되며 이 명세서는 서비스 저장소에 있는 핵심 서비스들을 실행시키는데 필요 관점 서비스 (aspect service) 서비스 에이전트로서 관점 명세서에 정의된 관점 규칙(aspect rule)에 따라 관점 위버에 의해서 예외처리와 같은 횡단관심사를 위해 동적으로 삽입되어 실행 재사용 가능한 소프트웨어 컴포넌트로서의 역할 저장소(repository) 서비스 에이전트와 예외 처리기와 같은 관점 서비스에 대한 서비스 명세 정보와 관점 명세서를 관리 온톨로지 저장소 시스템 내부에서 사용되는 도메인 온톨로지와 추상적인 예외 모델 온톨로지 그리고 서비스를 표현하는 서비스 온톨로지, 관점 트리를 갖음 관점 명세서 (aspect specification) 서비스 개발자가 핵심 서비스의 예외처리 기능을 담당하는 관점 서비스를 분리하기 위해 AOP 개념에 해당하는 포인트컷과 어드바이스 정보를 포함한 관점 규칙을 명시 관점 위버 (aspect weaver) 시스템적인 오류가 발생하였을 때 원래의 서비스와 기능 및 비기능적으로 동일한 서비스 에이전트를 동적으로 실행 해당 오류 부분에 대한 서비스 호출 메시지를 가로채기하고 처리할 관점 정보를 중개자로부터 받아 관점 서비스를 적용 서비스 관리자 (service manager) 동적 AOP를 이용한 신뢰성 있는 서비스 특성을 시스템에 반영하고 전체 시스템을 구성하는 과정을 지원

신뢰성 있는 관점지향 기법
웹 애플리케이션과 관점 명세 파일 사이에 중개자가 필요
중개자(Intermediary) : 관점 분석기(Aspect analyzer)와 관점 검사기(Aspect inspector)를 포함
관점 분석기 : 사용자에 의해 작성된 관점 명세 파일을 각 속성(attribute)별로 나누는 역할
관점 검사기 : 포인트컷의 매칭 문제와 중복 문제, 위빙 시 관점 간섭 문제 등이 생기지 않도록 내부 프로세스를 이용하여 방지
AOP의 적용 사례

구분 설명 AOP 적용전 (핵심로직 + 공통로직의 혼재) - 실행시간을 구하는 메서드가 변경될때마다 사용된 모듈을 모두 변경해야함 public void someMethod() { StopWatch stopwatch = new StopWatch(); stopwatch.start(); executeCoreLogic(); // 핵심 로직 stopWatch.stop(); long executeTime = stopwatch.getTotalTime(); // 공통 로직 } 공통 관심사항 구현 핵심모듈에 언제 삽입되는지를 구현(eg, LoggingAspect.java) 공통 관심사항 설정 (XML 형태로 AOP 설정) 삽입되는 공통 관심사항에 대한 정보를 설정함 - commonConcern.xml 파일 내용 // 모든 모듈에 적용 가능하다는 의미로 정규표현식을 사용 // 삽입하고자하는 Sprint 에서 제공하는 Crosscutting Concern Weaving 수행 설정한 공통관심사항 (xml 파일) 을 사용하여 구현한것과 같이 핵심 관심사항의 실행전 및 실행후에 공통관심사항 (Logging) 이 구현됨 public class MainForApp { public static void main(Strings[] args){ string[] configLocations = new string[] {commonConcern.xml} // 공통 관심사항 설정파일 적용 executeCoreLogic(); // 핵심 로직 } } 핵심모듈 실행 결과 메시지 ----- [2010-01-10] 20:10 – 기록 시작 CoreLogic 실행 메시지 ----- [2010-01-10] 20:15 – 기록 종료 메시지 ----- [2010-01-10] 20:15 – CoreLogic 실행시간: 5

프로젝트

프로젝트의 목적달성을 지원하는, PMO(Project Management Office) 가. 정의
체계적인 사업관리체계 구축과 발생 가능한 위험요소들에 대한 효과적인 관리 및 통제, 지원을 통해 정보화 사업의 성공적인 추진을 지원하는 조직
해당 영역에 있는 프로젝트들을 집중화하고 통합 관리하는 것과 관련된 다양한 책임을 할당 받은 조직부서 또는 주체
프로젝트 관리 능력을 향상시키고 발전시키기 위한 실질적인 사항을 제시하는 프로젝트 근간의 조직
대규모 IT사업의 품질관리나 일정관리, 산출물관리 등 프로젝트 전 분야를 총괄 관리하는 조직이나 인력
프로젝트 통제력 강화, 성공률 제고, 표준 절차의 확립
전체 정보기술 조직 내에 진행중인 복수의 프로젝트(신규 개발, 유지보수 등)에서 요구되는 자원 및 일정을 모니터링하고 진행과정에서 발생하는 이슈를 중재하는 조직 나. PMO 도입의 필요성
시스템 구축의 복잡도 증가와 다양한 복합기술의 적용에 따라 프로젝트의 예산과 목표를 완료할 수 있도록 지원하는 조기의 필요성이 증가
최근, 대기업의 참여제한 등의 법제도 변화와 분리/분할발주의 성공적인 도입을 위해서 PMO에 필요성이 확대되고 있는 추세에 있음
전사 프로젝트들의 우선순위화
프로젝트 추진방법을 표준화
리더십팀(경영진)에 프로젝트 가시성을 제공
프로젝트 투입 인력을 관리
프로젝트 경비 추적 및 보고
리스크 관리
역할과 책임 규정과 할당
템플릿 보고서 표준화
프로젝트로 인한 가치관리
고객만족 추적과 보고
성공적인 PMO도입을 위한 PMO Model 가. PMO의 Model의 구성

나. Role & Responsibility의 유형 - 리스크, 조직문화, 내부 역량, 규모 등의 특성 고려

다. PMO의 Type - 프로젝트의 규모, 관리 능력, Risk와 예산규모에 따라 PMO Type 선정

라. PMO Position - 조직의 성숙도에 따라 성숙도에 따라 PMO의 Position이 달라짐

PMO의 도입절차 및 유형 가. PMO의 구성
발주기관이 PMO를 도입하기 위해서는 일반적으로 ① PMO 도입여부 판단, ② PMO 수행주체 결정, ③ PMO의 예상 소요비용 및 인력에 대한 검토와 같은 단계를 거침
각각의 단계별로 해당 사업이 PMO를 도입할 특성과 규모를 지니고 있는지를 판단하고, 내부적으로 PMO를 관리할 역량이 있는 지와 사업자가 성공적으로 사업을 마칠 역량이 충분한지를 검토하여 외부 전문인력의 도입 정도를 검토
사업의 범위와 규모, 내부 사업관리 역량을 종합적으로 판단하여, 마지막으로 PMO를 수행할 때 소요되는 비용과 투입인력을 예상하여, PMO도입 여부를 판단 나. PMO의 도입절차

절차 내용 고려사항, 평가요소 PMO 도입 여부판단 사업의 특성이나 규모를 기준으로 PMO를 도입하여 사업관리를 수행할지 결정 사업난이도, 파급효과, 사업금액 사업기간, 전문인력, 수행경험 PMO 수행 주체결정 발주사 사업관리 능력, 사업자 사업수행능력을 기준으로 PMO 도입 시 외부인력 활용여부결정 내부자체, 일부외부, 사업관리 전반의 외부인력->PMO유형결정 PMO 모델 유형결정 사업의 범위, 규모와 내부 사업관리 역량을 기준으로 PMO 모델 유형 선택 일반적으로 사업규모에 따라 Repository -> Coach -> Manager형 바람직 PMO 예상소요 비용/인력 실제 PMO 도입 시 소요가 예상되는 비용과 인력의 추정 전체사업비 기준으로 적절한 소요비용추정(개발인력대비 적절한 비용 추정) PMO 조직구성 또는 발주 사업관리 총괄 및 의사결정자와의 의사소통 담당 PMO 사업실무 책임 등 전반적 사업관리형 PMO PMO 전문기관 또는 사업자 선정(발주) 기술지원(아키텍처, DB)등 IT 전문분야 지원/관리로 구성 PMO 운영준비 및 착수 PMO 환경 조성(사업환경 이해, PMO 요건정의, 세부조직) 발주기관과 PMO 상호간 역할 및 책임 정의 PMO 운영계획서 작성

다. PMO의 유형

구분 유형 특징 역할 측면 Repository 형 단순 프로젝트 목록 및 진척상황 공유, 취합 및 보고 Coach 형 공통방법론/SW도구 사용 전파, 의사소통 중계(PJT팀 간) Manager 형 중앙집중식, 의사결정관여, PM Pool 역할 인력구성 측면 발주자 중심 비즈니스 이해도 향상 장점, 감리조직과 연계 수주자 중심 개발사 비용/일정/위험관리 가능, PJT환경 이해도 높음 혼합 형태 Hybrid형태, 감리+현업+IT개발사 등 역할분담

PMO의 주요 기능 1) 프로젝트 관리 원칙 수립 및 프로젝트 관리 프로세스 표준화 2) 프로젝트 현황에 대한 모니터링 및 체계적인 보고체계 구축, 정보공유 3) 방법론 및 도구 개발, 교육 및 전파 4) 프로젝트 포트폴리오 관리 및 위험관리 체계 수립 5) 산출물에 대한 Quality 확보 6) 프로젝트 수행시 문제해결 : Technical Support
PMO 기대효과 1) 체계적인 사업관리를 통한 사업의 성공적인 완료를 지원

구분 내용 정량적 성과의 정량적 구체화 위험의 정량화 관리목표 및 목적의 가시성 강화 정성적 전략과 노력, 활동, 산출물의 효과적인 연계 원활한 Communication 조직의 변화관리 능력간의 상호 의존성 강조

2) PMO를 통한 기술 및 지식의 전수로 주관기관의 사업관리 역량 강화 3) PMO 도입기간에 따른 단계별 예상효과 - 도입 초기 : 교육 및 협업을 통해 외부 PMO조직의 지식과 기술을 전수 - 도입 중기 : 외부 PMO조직의 사업관리 방법론 및 노하우 전수를 완료하여 내부 인력과 외부 PMO조직과 동등한 수준이 됨, 전수 받은 지식과 기술을 활용하여 자체 사업관리 수행 가능 - 도입 후기 : 외부 PMO 조직의 방법론 분석을 완료하고 각 조직 및 사업특성을 고려하여 방법론을 Customizing 및 적용 가능함 5. PM과 PMO 차이점/정보시스템 감리 및 PMO 차이점 및 PMO 종류 가. PM과 PMO 차이점

구분 PM PMO 주체 프로젝트 매니저 경영층, 전담조직 관리대상 프로젝트 프로젝트 포트폴리오 프로젝트 제약조건 통합관리 위험관리, 자원관리, 진척 관리 방법론 적용 목표 프로젝트 성공적 완료 조직의 목표 달성

나. 정보시스템 감리 및 PMO 차이점

구분 정보시스템감리 PMO 법적근거 전자정부법 제57조 1항에 따른 의무사항 법률상 근거 규정 없음 관점 발주자, 사업자와 독립적 입장 발주자 입장에서 사업자 관리 역할 문제발생 여부 사후 검증 기능(설계결함 등 기술 측면) 문제발생에 대한 사전 예방 기능(일정/범위 등 관리 측면)

다. PMO의 종류

종류 세부 내용 Project PMO 개발작업의 초기에 시작해서 안정적인 시스템 런칭 지원 표준 개발 프로세스와 룰을 결정, PMO를 훈련하고 코칭하는 역할 개별 IT 프로젝트의 품질, 납기, 비용차원의 목표 달성과 PM 역량강화 목표 Highly Engineering & Low Strategic Job 수행 Program PMO 사업초기에 시작해서 보다 복잡한 프로젝트 조정역할 수행 비즈니스와 IT 프로젝트의 조율에 집중하여 전체 프로젝트 관리 의사소통과 변화관리 주관 등의 프로그램 수준의 역할 수행 Middle Engineering & Strategic Job 수행 Portfolio PMO 사업을 만들고 투자전략을 만들고 보다 복잡한 전사 프로그램 조율 전사 전략대비 최적의 IT 프로젝트 MIX 수립과 IT 성과를 주로 관리 Low Engineering & High Strategic Job 수행

사업 단계별 PMO의 역할

사업단계 PMO역할 기획 및 착수 제안요청서(RFP), 작성지원(기술검토, 용량산정), 사업자 선정 지원(기술협상, 하도급적성판단) 집행 계획 대비 이행실적 점검, 위험요소 파악‧대응, 기술적 쟁점 검토 등 종료 산출물의 품질검토, 발주자의 인수시험‧검사 등 지원

PMO의 7개 영역 기대효과

영역 기대효과 프로젝트 지원 각 사업부문의 프로젝트 관리자들에게 프로젝트의 관리 지침을 제공 프로젝트 관리 프로세스/방법론 일관적이고 표준화된 프로세스를 개발하고 구현 훈련 훈련 프로그램을 시행하거나 회사 외부를 위한 요구사항들을 수집 프로젝트 관리자들을 위한 고향 중앙집중형 사무실을 유지하면서 프로젝트별로 프로젝트 관리자들을 각 사업부문에 파견 내부 컨설팅 및 개인적 스승 직원들에게 베스트 프랙티스에 대해 조언 프로젝트 관리 소프트웨어 도구 직원들이 사용하는 프로젝트 관리 도구를 선택하고 유지보수 포트폴리오 관리 프로그램 관리자 스탭조직을 만든 후 한 사람의 프로그램 매니저가 인프라 기술, 데스크탑 애플리케이션 등 관련이 있는 복수의 프로젝트를 관리를 맡긴 다음 그들에게 적절하게 자원을 할당

PMO가 재무적으로 영향력을 발휘할 수 있게 해 주는 방법 ● 프로젝트를 관리하기 위한 표준 방법론 제공 ● 프로세스와 프로젝트의 보고 및 추적 작업에 대한 책임자 지정 ● 비슷한 프로젝트는 비슷한 방법으로 확실하게 수행되도록 규정 ● 프로세스의 속도를 높이거나 낮추는데 필요한 정보 확보 ● 자원 할당과 용량 관리를 위한 프로세스 제공 ● 프로젝트를 회사의 전략 및 운영 계획과 확실하고 직접적으로 연계
PMO가 전략적으로 영향력을 발휘할 수 있게 해 주는 방법 ● 프로젝트를 회사의 전략적 및 운영상 계획과 직접적으로 연계 ● 프로젝트를 관리하기 위한 표준 방법론 제공 ● 고위 경영진의 후원/지지 확보 ● 프로젝트 프로세스, 선택, 우선순위 매기기, 실행 등을 각기 책임진 그룹들을 확실하게 연계 ● 비슷한 프로젝트는 비슷한 방법으로 확실하게 수행되도록 규정

EPMO(Enterprise Project Management Office, Enterprise PMO, 전사 PMO) 가. 정의
프로젝트와 아키텍처, 거버넌스, 비즈니스 혁신 등을 관리하는 PMO의 역량을 기업 IT조직의 역량으로 내재화
CIO가 수립한 IT전략과 IT포트폴리오 체제에 맞춰 IT프로젝트들이 올바르게 수행되고 있는지 실시간 관리하는 것이 EPMO
CIO와 PMO 사이에서 IT포트폴리오에 따라 프로젝트들이 수행되고 있는가를 점검하고 조정하는 것이 EPMO의 역할
기업 아키텍처 관리자의 역할도 병행 나. 필요성
급변하는 시장 환경과 기업 전략이 훨씬 더 높은 수준의 기업 내부 IT역량을 요구
프로젝트 관리와 프로젝트관리조직(PMO)의 중요성은 계속 커짐
PMO를 특정 대형 프로젝트 추진 시에만 구성, 운영해서는 기업이 처한 변화의 속도에 발맞출 수 없음
PMO와 EPMO 비교 및 EPMO 구성 가. PMO와 EPMO 비교

구분 PMO EPMO 관리범위 특정 프로젝트 관리 횡적, 종단 간 프로젝트 관리 포트폴리오 부합 여부 관리 IT아키텍처까지 확대 관리 요구되는 능력 특정 IT부문에 대한 전문성 IT 전 부문에 대한 폭넓은 전문성 기업 IT관리에 대한 이해도 비즈니스 이해도 수요 금융권 차세대 중심 지주회사 및 IT셰어드서비스 환경으로 수요 확대 인적구성 외부 사업자(컨설팅 업체) 현업(기업전략), 내부IT인력 외부 전문가(컨설팅)

나. EPMO 구성 1) S-PMO(전략적 PMO) - 기업 전략의 궁극적인 목표를 이해하는 사람, 즉 현업 인력이 중심 - 기획 단계의 프로젝트가 많은 경우 2) M-PMO(관리 PMO) - 프로젝트 관리를 수행하기 때문에 IT인력 - 내부 인력으로 완전히 충족될 수 없는 전문성을 보강하기 위해 컨설팅 업체와의 장기 계약을 맺을 수 있음 - 착수한 프로젝트가 많은 경우 3) C-EPMO - 상시적(Continuous)이며 포괄적인(Enterprise-wide) PMO 조직

I. 정량적인 프로젝트 진행 척도, EVM(기성고)의 개요 가. EVM(Earned Value Management,기성고)의 정의 - 현재 실적으로 달성된 작업 가치를 산출, 계획대비 실적을 관리하고 향후 성과(일정, 비용)를 예측하는 프로젝트 관리활동 - 최적의 프로젝트 계획과 통제를 위한 일정/비용 요소로서 프로젝트 작업 범위를 효과적으로 통합하여 관리하는 프로젝트 관리기법 - 프로젝트별 일정과 비용을 통합 관리함으로써 성과 분석 및 프로젝트 최종 사업비용과 일정을 예측하는 기법 - 전체 완료단계 100%로 봤을 때 현재 몇%까지 완성되었는지를 나타내는 척도 나. 기성고의 필요성

비용과 일정관리의 어려움, 책임소재 불명확
일정, 비용의 문제점 조기발견과 대책수립의 필요성
현재 획득 가치 대비 일정지연, 추가비용의 통제 필요성
현재의 일정과 비용에 근거하여 종료 시점의 비용 소요, 일정 예측
단순비용, 일정이 아닌 실질적 획득 가치 관점의 프로젝트 통제 II. 기성고의 관리 절차 및 구성요소 가. 기성고의 관리 절차

1) 프로젝트 종료를 위한 모든 작업 범위를 계획(베이스 라인 설정) 2) 계획된 베이스 라인과 비교하여 실행된 프로젝트의 작업 범위, 일정, 비용 요소를 측정 3) 작성 성과(Performance) 수준을 객관적으로 평가 4) 계획과 비교하여 주요 변수를 분석하고 그 영향을 예측 5) 이를 해결하기 위한 결정과 실행을 위해 좀 더 수준 높은 데이터 준비 6) 프로젝트 초기에 프로젝트의 전망을 예측하고 필요한 경우 조기 위험을 제거 할 수 있게 계획을 수정 나. 기성고의 구성요소

계획가치(PV), 획득가치(EV), 실제원가(AC)의 세 값을 모두 활용하여 성과를 측정하면 지정된 시점에서 계획대로 작업이 완료되는지 여부를 판단가능 III. 기성고 관련 공식

공식 설명 BAC Budet at Completion(전체 프로젝트에 할당된 예산) : 계획된 Value의 총합 SV=EV-PV Sechedule Variance(일정계획 대비 차이) : 양수이면 일정단축, 음수이면 일정초과 CV=EV-AC Cost Variance(원가 계획 대비 차이) : 값이 양수이면 비용절감, 음수이면 비용초과 SPI=EV/PV Schedule Performance Index : 값이 1보다 크면 일정성과지표 양호 CPI=EV/AC Cost Performance Index : 값이 1보다 크면 비용성과지표 양호

예) 기출문제 풀이 (93회 관리 2교시) 가. 프로젝트 개요 및 측정 요소

• 사업예산 : 1,600,000 천원 • 사업기간: 16개월 • 현황 : 4개월 경과, 400,000천원 지급, 작업 수행률 20%

PV = 1,600,000천원 * 4/16개월 = 400,000천원 EV = 1,600,000천원 * 20% = 320,000천원 AC = 400,000천원(총 지급금액) 나. 분석 요소 CV = EV-AC = 320,000천원-400,000천원 = -80,000천원(음수=비용초과) CPI = EV/AC = 320,000천원/400,000천원 = 0.8 (1미만=비용초과) SV= EV-PV = 320,000천원-400,000천원 = -80,000천원(음수=일정지연) SPI= EV/PV = 320,000천원/400,000천원 = 0.8(1미만=일정지연) - 사업은 현재 비용이 초과되며, 일정이 지연된 상태임 다. 예측 요소 EAC= BAC/CPI = 1,600,000천원/0.8=2,000,000천원 - 예산대비 400,000천원 초과 예상 예) 문제 풀이 프로젝트 일정과 원가관리를 하기위한 EVM에 대해서 설명하고 아래의 예제에 대해 EVM을 적용하여 EV, CPI, SPI, TCPI를 구하고 원가 및 일정에 대한 현시점에서의 측정을 하시오 - 프로젝트수행을 위해 시간당 2만원인력 20시간소요 - 현재까지 투입시간 15시간, 시간당 3만원 인력투입 - 프로젝트완료를 위해 10시간 투입예상 - 해설

측정지표 계산식 지표값 PV 실제투입시간/최초예상시간 최초예상금액 15/20202만원=30만원 30만원 AC 실제투입된돈 : 15시간3만원 45만원 EV 진척율예상금액(60%40만원) 24만원 진척율 현재투입시간/(투입시간+남은시간)*100 15/(15+10) * 100 = 60% 60%

예) 문제 풀이 대규모 웹기반 시스템 구축프로젝트를 진행 중이다. 코딩부분만 외주 인력을 고용하여 추진하고 있다. 개발자 생산성을 측정해본 결과 3명이 4일동안 8개의화면을 구축할 수 있다. 개발자 인건비는 일당10만원이다. 현재 시점에서 160개의 화면을 개발 완료했고, 이때 지급한 인건비의 총합이 3400만원 이었을 경우 CV는 얼마인가 ? - 해설 화면 1개당 15만원(3명 * 4일 *10만원 / 8개화면), 현재 160개를 완료했으므로 EV = 160개 * 15만원 / 평 = 2400만원 CV = EV - AC = 2400만원 - 3400만원 = - 1000만원 IV. 기성고의 적용시 문제점 및 해결방안, 적용방안 가. 문제점 및 해결방안 - 실제 Actual Cost 측정의 어려움, 시기별 추정 잔여량의 변화가 폭이 큼 - 시간과 비용 이외의 프로젝트에 영향 요소 발생 - 프로젝트 진행에 따른 보정율 계산, 목표 품질과 범위 변경에 따른 영향요소 반영 나. 적용방안 - 주기적인 모니터링 필요(현재의 비용, 일정 현황과 미래의 비용, 일정예측) - PMO등을 통한 거버넌스 측면의 전사적인 관점에서 통제/관리 활동이 필요함

I. 프로젝트의 수행을 위한 첫발, 발주 프로세스의 개요 가. 발주 프로세스의 정의 - 기업 또는 국가가 정보시스템 또는 소프트웨어 도입을 목적으로 사업을 기획하고 입찰 공고, 사업자 선정을 하는 과정 - 양질의 IT 서비스 또는 시스템을 도입하기 위한 절차로써 발주자와 수주자가 공동으로 실시해 가는 작업 및 관련 활동 나. 발주 프로세스의 필요성

구분 발주자 공급자 재무관점 예산범위 내에서의 프로젝트의 최대비용을 설정 최대비용 내에서의 효율적인 프로젝트 수행방안을 제시 고객관점 기대수준, 요구사항을 정의하고 이에 알맞은 공급자를 선점 할 수 있는 최적의 공급자 선택 고객의 기대수준에 맞는 프로젝트 공급 방법에 대한 이해 내부프로세스 프로젝트의 기획, 제안, 확정에 이르기 까지 위험요소를 사전에 식별 가능 제안팀의 구성, 제안의 범위, 제안의 일정 등 성공적인 제안을 위한 전략 수행 학습 및 성장 발주자와 공급자간의 질의/응답을 통해 필요사항을 명확히 하여 구체적이고 직관적인 요구사항 정의

II. 발주프로세스의 절차 구성도 및 구성요소 가. 발주프로세스의 절차 구성도

발주자는 프로젝트 문제정의에 대한 질의 응답(RFI) 실시, 제안요청서(RFP) 작성하여 공급자의 제안서(Proposal)을 평가, 공급자를 최종 선정함. 나. 발주 프로세스의 절차 구성요소

구분 설명 작성사항 RFI 정식제안요청 이전에 수행하여 공급업체의 업무현황 및 수행능력을 개략적으로 파악하여 후보업체를 선정하고 제안 요구사항을 확인 사업개요, 발주업체정보, 주요 요구사항 RFP 공급업체의 제안서 평가를 통해 고객이 원하는 서비스를 얻기 위한 목적 사업개요, 제안프로젝트 일정, 정보요구내역, 기술적 환경 정의, 제안서관련 요구사항 Proposal 고객의 요구사항이 잘 반영, 공급자만의 프로젝트의 수행 매력을 표현하여 제안평가로부터 높은 평가를 받을 수 있도록 작성 제안개요, 제안업체 일반현황, 제안내용, 사업관리부문, 지원부문 및 기타

III. 발주 프로세스의 공급자 선정 기법(예)

구분 설명 가중평가 시스템 Weighting System 사전에 정한 가중치에 따라 항목을 평가하는 방법 사전 필터링 시스템 Screening System 입찰에 참여할 수 있는 공급자의 최소 기준을 제시하여 부적합한 공급자를 사전에 배제하는 방법 예정가격 산정 Independent Estimates 업무수행을 위한 적정가격(예정가격)을 사전에 도출하여 차이가 큰 업체를 배제하는 방법 공급자 평가 시스템 Seller Rating System 공급자의 과거 수행 실적, 품질 등급 등을 평가하는 시스템으로 제안서 평가와 함께 공급자 선정을 위하여 활용함

I. 제안 요구사항의 확인, RFI의 개요 가. RFI(Request For Information, 정보요청서)의 정의 - 발주자가 RFP 작성 전 프로젝트 계획/수행에 필요한 자료를 수집하기 위해 공급업체에 요청하는 정보요청서(사업개요/발주업체정보/요구사항) 나. RFI의 목적 - 정식 제안요청(RFP) 이전에 RFI 수행을 통해 공급업체의 업무현황 및 수행 능력을 개략적으로 파악하여 후보업체를 선정하고, 제안 요구사항을 확인 II. RFI의 구성요소

항목 내 용 사업개요 사업명, 추진 배경 및 목적, 사업범위, RFI제출요령 등 발주업체 정보 일반현황(사업목표/추진방향 등), 정보시스템 현황, 개선사항 등 주요 요구사항 세부 업무관련 요구사항, 기술적 요구사항, Implementation, 교육, 성능향상, 프로젝트 관리 등 공급업체 정보 요청 공급업체의 회사소개(연혁, 재무구조, 인원구성 등), 경영전략 및 환경, 주요프로젝트 추진실적, 유사분야 경험, 보유한 방법론, 보유한 툴 및 정보기술

IV. RFI 고려사항 - 발주자의 필요사항(요구사항 반영) : 3~5개 공급업체를 복수로 결정

I. 원하는 서비스를 얻기 위한 제안요청서, RFP의 개요 가. RFP(Request For Proposal)의 정의 - 발주자가 정보시스템을 구축하기 위해 필요한 요구사항을 체계적으로 정리하여 공식적으로 제안을 요청하는 문서(사업개요/일정/요구사항/기술환경) 나. RFP의 목적 - 공급업체의 제안서 평가를 통해 고객이 원하는 서비스를 얻기 위한 목적 - 사업에 대한 요구사항을 명확히 정의함으로써 사업범위와 목적을 확인함 - 공급자에게 요구사항이 잘 전달되도록 충분한 지침, 방향, 정보를 주기 위함->기술적인 부분에 오류나 혼동이 있을 경우, 사업자 선정과정 이외에도 사업기간 전체에 걸쳐 심각한 결과를 초래 - 제안서의 평가, 향후 사업전체에 있어 사업목적에 대한 추적성을 제시 - 사업기획단계부터 제안, 입찰, 계약, 수행, 유지보수 전 단계에서 요구사항 제시 II. RFP의 구성요소

항목 내 용 사업개요 제안배경, 추진 목적 등 프로젝트일정 제안서 제출 마감일정 및 발표일정, 업체선정 발표일, 개략적인 프로젝트 추진일정 정보 요구내역 서비스 제공자명, 조직 및 인력 구조, 관련분야 추진내역(주요 사업내용 및 고객명 등), 주요 보유기술 내역 등 기술적 환경 현재 기술현황(하드웨어, 소프트웨어, 네트워크), 시스템 아키텍처(현재 및 미래모델) 주요 요구사항 제안 목차, 공급업체의 핵심인력 및 참고자료, 제안형식 및 제출부수, 제안서 제출장소, 질의 문의처 및 각종 선정기준

III. RFP와 RFI의 비교

항목 RFP RFI 작성항목 현재 발주자의 상황, 원하는 사업목표, 문제점을 제시 정식제안요청 이전에 공급자 수준확인 및 제안요구사항 확인 작성사항 사업개요, 프로젝트 일정, 요구사항, 기술적 환경, 사업예산 사업개요, 발주자 정보, 주요정보 요구사항, 필요사항 고려사항 RFP의 내용에 발주자의 요구사항을 명확하게 제시해야 함 3~5개 복수업체에 발송

IV. RFP 고려사항 - 제안서 내용에 고객 요구사항이 잘 반영될 수 있도록 공급업체에게 제안 작성을 위한 명확한 지침, 방향 및 충분한 정보를 줄 수 있는 RFP를 작성

I. SW산업의 공정한 거래질서 형성을 위한 상세 RFP제도. 가. 상세 RFP의 정의 - 발주 준비 단계에서 사업 목표와 범위에 대한 승인 절차를 강화하여 이해관계자들간의 혼란을 최소화하고 프로젝트 감독 및 성과관리를 강화하는 선진 발주 방식 - 정보 시스템의 구축범위, 요구사항 등을 자세히 분석한 뒤 세부 내용을 명시하는 RFP 작성방법 - '공생발전형 소프트웨어(SW)생태계 구축전략'의 후속조치로 선진적인 수발주체계 구축을 위해 정부가 추진하는 제도로 전문화된 표준 RFP 생성을 위해 요청사항 상세화, 검증 방법론 및 성능․품질, 요구사항 상세화, 요구사항 연계관리 기능 등 보완하여 작성한 RFP - 사업 발주를 위한 RFP 작성시 요구사항이 불분명한 바, 초기 분석설계 수준의 상세 요구사항 작성을 위한 컨설팅을 실시하고 상세한 RFP 작성 나. 상세 RFP의 등장배경 - 일반적으로 작성해온 RFP는 상세하지도 구체적이지도 않은 경우가 많음 - 요구사항이 명확하지 않으니 요구사항에 대해 발주자와 수주자의 생각이 다른 경우가 많음 - 발주자가 새로운 요구를 하는 경우 프로젝트 중간에 과업이 바뀌어 다시 작업을 해 프로젝트 기간이 늘어나고 전체적으로 품질이 떨어지는 문제가 발생 - 불합리한 과업 변경, 분석ㆍ설계 단계의 지연과 개발 일정의 축소, SW 개발자들의 과도한 노동과 같은 문제가 발생 - 정보화사업 추진시 불명확한 요구사항과 잦은 과업변경으로 인한 사업자 부담 증가와 정보 시스템 품질 저하 문제를 최소화하기 위한 방안의 하나로 필요성이 제기 - 공공 정보화사업의 선진 발주제도(상세RFP․MO제도)는 지난 ‘11년 10월 27일에 발표된 ｢공생발전형 SW생태계 구축전략｣의 후속조치로 선진적인 수․발주체계 구축을 위해 추진됨 - 공공 SW사업의 품질을 제고하고, 국내 SW기업의 전문성과 국제경쟁력을 강화하기 위해 SW사업 수발주 단계에서 선진 제도의 도입 필요성이 높아짐 - SW사업 추진시 불명확한 요구사항과 빈번한 과업변경으로 고급인력 이탈 및 SW사업 품질저하 등 SW산업 생태계 악화 초래 - 공공부문 SW사업 75.2%가 사전 기획사업(EA/ISP 등) 未수행, RFP의 60.1%가 외부 도움 없이 발주부서에서 직접 작성(‘09.11, 공공부문 실태조사, NIPA) 다. 불명확한 RFP 발생이유 - 외부 도움 없이 발주부서에서 작성하거나 정보화 사업을 직접 수행할 가능성이 높은 IT서비스 기업의 도움을 받아 RFP를 작성 라. 상세 RFP 특징

특징 설명 요구사항 상세화 기능 요구사항은 기능점수 도출 수준까지 각 기능에 대해 처리 절차와 방법, 입출력 데이터 기술 시스템, 성능, 보안, 품질 등의 비 기능 요구사항 상세화 기능검증 및 성능, 품질 요구사항 상세화 기능을 검증하기 위한 절차와 방법을 기술하여 요구사항 만족 여부 평가 만족해야 하는 성능 및 품질을 측정 가능한 요구사항으로 기술 요구사항 연계관리 서로 관련이 있는 요구사항들을 명시하여 상호 교차 추적이 가능하도록 구성

마. 상세 RFP 적용방법

II. 상세 RFP 및 PMO제도의 핵심사항 가. 상세 RFP 및 PMO제도의 개념도.

기본설계 단계까지 발주기관의 요구사항을 명확히 도출하여 발주자 의도에 부합한 사업 수행 나. 상세 RFP 및 PMO제도의 핵심요소

구분 내용 RFP사업 문서화된 표준 RFP 생성을 위해 요청사항 상세화, 검증 방법론 및 성능․품질, 요구사항 상세화, 요구사항 연계관리를 위해 별도의 컨설팅 실시 PMO 성공적 사업수행을 위한 전문 지원조직, 기획․구축․운영 등 관리전문 조직 필요 분할발주 PMO의 감독․통제 아래, 요구사업(ISP부터 설계까지 SW사업 요구사항과 아키텍처 정의, 시스템 기본설계 수행)과 개발사업(기본설계에 기초하여 개별기능이나 제품단위로 개발 수행)으로 분할하여 수행하는 발주방식

III. 상세 RFP 및 PMO제도의 향후 전망 - 한전등 지경부 60개 유관기관은 올해 시범적용을 통해 관련 SW산업에 새로운 시장이 창출될 것이며 이는 업계에 새로운 활력소가 될것이며, 내년부터는 공공기관 정보화시장에 본격 도입 - 요구사업 구체화, 설계․공정개발의 분업화․전문화를 통해 국내 SW사업 품질 제고 및 기업 국제경쟁력 확보 등 선진 생태계 조성 - 상세 RFP와 PMO제도는 시스템 개발품질을 향상시킬 뿐만 아니라 SW산업의 공정한 거래질서 형성 - RFP컨설팅과 PMO시장이 조성될 수 있고 제도설계에 필요한 교훈과 정보를 획득할 수 있어, 선진 발주제도의 성공적 도입이 가능 Ⅳ. 상세 RFP와 기존 RFP 비교

Ⅴ. 상세 RFP의 장점 - 정보 시스템의 구축범위, 기술요건, 요구사항 등을 분석해 요구사항을 상세하게 도출하고 분류해 세부내용을 명시 - 사전 발주기획 단계에서 사업에 대한 목표인식과 분석을 통해 이해관계자들의 혼란을 최소화하고 사업의 성공 가능성을 높일 수 있음 - 발주자 : 발주기획과 분석 설계, 사업자는 제안서 작성, 계약, 검수단계에서 업무개선 효과가 높음 - 분할발주, 프로젝트 관리조직(PMO) 등 다른 대책들과 잘 융합돼 시행되면 공공 정보화 사업의 성공 확률을 높이는 것은 물론 SW 개발자의 과도한 업무 개선 등 SW산업에 도움이 될 것으로 기대

I. 업체 선정의 기초자료, 제안서의 개요 가. 제안서의(Proposal) 정의 - 프로젝트를 발주할 때 수주업체의 개발 경험이나 능력, 기술적 특징 등을 분석하기 위해 제출 받는 문서 나. 제안서의 목적 - 업체 선정의 기초자료로서 사전에 업무 파악을 할 수 있는 근간이 되며 사업 수주 시 업무이해도를 높일 수 있는 역할 - 제공하게 될 제품이나 서비스의 범위를 명확하게 구분하여 분쟁요소 소멸 - 업체 선정을 위한 기술 수준의 사전 평가 - 공급자는 제안서를 작성, 제출함으로써 기술력 재정리 및 공급자의 보유 기술 홍보 활용 II. 제안서의 내용 및 목차 예시 가. 제안서의 내용

목차 내용 제안의 개요 제안서의 내용을 개략적으로 요약 배경, 목적, 범위, 제안서의 특장점, 사업수행전략, 사업수행을 위한 전제 조건 등 제안 내용 프로젝트 관리방안 : 범위, 일정, 형상, 품질, 조직관리 등 프로젝트 수행방안 : 개발방법론, 개발도구, 적용기술 유지보수 방안, 교육훈련 계획 등 제안업체 일반 정보 제안사 일반현황(매출, 인력, 주사업분야, 재무구조, 사업수행조직, 유사사업 수행실적 등) 보유기술(보유 솔루션, 브로셔, 특허 등 특장점 기술) 가격 제안 별도 밀봉 제출

나. 제안서 목차 예시(행정기관 정보화 사업)

I. 제안 개요 II. 제안업체 일반 1. 일반현황 2. 조직 및 인원 3. 주요사업내용 4. 주요사업실적 III. 제안 기술사항 1. 시스템 구성도 2. 시스템 구축방안 가. 시스템 사양 및 기능 나. 구성장치내역 및 세부규격 다. 시스템 납품 및 설치방안 3. SW개발방안 가. 개발방법론 활용방안 나. 업무 개발방안 다. 초기 데이터 구축방안 라. 시스템 통합 방안 마. 산출물 내역 4. 표준화 방안 5. 시스템 시험 방안 6. 시스템 운영 방안 7. 향후 시스템 발전 방향 IV. 사업관리부문 1. 품질보증계획 2. 위험관리계획 3. 추진일정계획 4. 업무보고 및 검토계획 5. 수행조직 및 업무분장 6. 투입인력 및 이력사항 V. 지원부문 1. 교육훈련계획 2. 유지보수계획 3. 기술이전계획 4. 기타지원사항 VI. 기타 별첨: 가격산출근거서, 하도급승인신청서, 기타증빙서류

III. 제안서의 작성 원칙 및 작성 방안 가. 제안서의 작성 원칙

원칙 내용 보편성 누가 읽더라도 이해할 수 있고 수긍할 수 있도록 작성 현실성 수주를 위해 허황되거나 실현가능성 없는 제안을 하지 않도록 함 구체성 전체 항목들이 유기적으로 연계되도록 작성 제안요청서의 요구사항이 모두 포함하여 기술

나. 효율적인 작성 방안

구분 내용 발주자 측면 - 전체 프로젝트 규모를 고려한 상세, 정확한 제안 필요 공급자 측면 - 발주된 사업의 프로세스를 명확히 이해, 발주자가 의도하는 목표 달성에 성공적인 수행 방법 도출 - 최적의 예산, 일정에 맞게 수주사의 리스크를 최소화, 이익을 극대화할 수 있도록 구축 계획수립 - 계획수립 단계에서부터 제반 프로젝트 관리 방안을 제시

I. 프로젝트의 성공과 납기 준수를 위한 일정 관리의 개요(Schedule Management) 가. 일정관리(Schedule Management)의 정의 - 프로젝트 납기를 준수할 수 있도록 개발 기간을 단계별로 계획하고 진행 상황을 감시하고 통제하기 위한 프로젝트 관리 기법 - 프로젝트를 성공적으로 완성하고 납기를 준수할 수 있도록 개발기간을 Activity, 단계별로 철저히 계획하고 수립하는 과정으로 개발단계가 일정계획에 준해 잘 진행되고 있는지를 감시하고 통제하기 위한 수단을 제공 나. 일정 관리의 중요성 - 프로젝트 성공적 완료를 위해서는 수행 가능한 일정수립이 필수 - 프로젝트 수행 중 일정에 차질이 발생하는 경우 대비책 필요 다. 일정관리의 특징 - 일정 관리의 목적 : 납기 준수 - 일정관리의 분야 : 작업식별, 순서파악, 기간추정 II. 일정 관리 개념도 및 구성요소 가. 일정 관리 개념도

나. 일정 관리 구성요소

구분 내용 Activity Definition (활동정의) 목 적 다양한 프로젝트 인도물(산출물)을 생성하기 위해 수행해야만 하는 Activity들을 식별 투입물 WBS, 범위 기준선, 기업 환경 요소(EEF), 조직 프로세스 자산(OPA) 도 구 분할, 연동 기획(Rolling Wave Planning), 템플릿, 전문가 판단 산출물 Activity 목록(속성), Milestone 목록 Activity Sequencing (활동순서 결정) 목 적 Activity 사이의 관계를 식별하여 문서화 투입물 Activity 목록(속성), Milestone 목록 도 구 PDM, ADM, 종속성 결정, Lead와 Lag, 일정 네트워크 템플릿 산출물 일정 네트워크 다이어그램 Activity Resource Estimating (활동자원 산정) 목 적 각 Activity 수행에 필요한 자원의 종류와 양을 산정 투입물 Activity 목록(속성), 자원 달력 도 구 전문가 판단, 대안 분석, 출판된 산정 데이터, 상향식 산정 산출물 활동 자원 요구사항, 자원 분할 구조(RBS) Activity Duration Estimating (활동기간 산정) 목 적 산정된 자원으로 개별 Activity를 완료하는데 필요한 기간 산정 투입물 Activity 목록(속성), 활동 자원 요구사항, 자원 달력, 프로젝트 범위 명세서 도 구 전문가 판단, 유추 산정, 모수 산정, 3점 추정, 예비 자원 분석 산출물 활동 기간 산정치 Schedule Development (일정개발) 목 적 활동순서, 기간, 자원 요구사항 및 일정제약사항을 분석하여 프로젝트 일정 수립 투입물 Activity 목록(속성), 일정 네트워크, 자원 요구사항, 자원 달력, 활동 기간 산정치, 프로젝트 범위기술서 도 구 일정 네트워크 분석, CPM, CCM, 자원 평준화 기법, What-If 시나리오 분석, 선도 및 지연적용, 일정 단축, 일정 도구 산출물 프로젝트 일정, 일정 기준선, 일정 데이터 Schedule Control (일정통제) 목 적 프로젝트 상태 감시, 일정 기준선에 대한 변경관리 투입물 프로젝트 관리 계획, 프로젝트 일정, 작업 성과 정보 도 구 성과검토, 차이분석, 프로젝트관리 소프트웨어, 자원평준화, What-If 시나리오 분석, 선도 및 지연조정 산출물 성과 측정치, 변경 요청

가. 일정관리 프로세스

나. 프로세스 구성요소

프로세스 내용 Activity Definition (Activity 도출) WBS를 근거로 하여 개별 Activity를 도출 프로젝트를 수행하기 위한 작업 부분을 식별 Activity Sequencing (선후관계정의) Activity간의 선후관계를 정의 프로젝트 내의 작업 종속성을 식별하고 문서화 Activity Resource Estimating(자원산정) 각 Activity를 완료하기 위해 필요한 자원의 종류와 양을 산정 Activity Duration Estimating(기간선정) 각각의 Activity들을 완료하는데 필요한 작업기간 산정 Schedule Development (일정개발) Activity 순서, 기간 및 필요한 자원의 소요 등을 분석하여 전체 프로젝트의 일정을 결정 Schedule Control (일정관리) 프로젝트 일정의 변경을 통제

Ⅲ. 활동 순서 결정 기법(네트워크 다이어그램) 가. 선후행 도형법(Precedence Diagramming Method, PDM)

주공정법(CPM)의 하나로, 노드라고 하는 사각형을 사용하여 활동을 표시하고 화살표로 연결하여 논리적 관계를 표현
AON(Activity-on-node) 기법
4가지 연관 관계 표현이 가능
FS(Finish-to-start) : 선행 작업을 완료해야 후속 작업에 착수, 가장 일반적
FF(Finish-to-finish) : 선행 작업을 완료해야 후속 작업을 완료
SF(Start-to-finish) : 선행 작업을 착수해야 후속 작업을 완료
SS(Start-to-start) : 선행 작업을 착수해야 후속 작업을 착수

나. 화살 도형법 (Arrow Diagramming Method, ADM)

화살표를 이용하여 활동을 표시
AOA (Activity-on-arrow) 기법
각 활동의 의존관계를 보여주기 위하여 각 마디에 연결
선행 작업 완료 후 후속 작업 착수(FS : Finish-to-start) 관계만 표현
모든 논리 관계를 정확히 명시하기 위하여 모조(Dummy) 활동을 사용 다. PDM과 ADM의 비교

항목 PDM ADM 특징 활동을 노드 위에 표현 화살표는 활동 사이의 관계 활동을 화살표 위에 표현 노드는 활동의 시작/종료 연관 관계 표현 FS, FF, SF, SS FS 장점 활동/단계 표시 가능 PERT/CPM에서 널리사용 작성이 쉬움 단점 작성이 어려움 활동만 표시, 단계 표시 불가능

라. 주요도구 도구 및 기법

기법 설명 주공정법 (Critical Path Method : CPM) - 원가절감에 주 목표를 두고 구현되는 프로젝트 관리 계획 및 통제 기법 - Critical Path란 여유기간(total float)이 없는 작업들의 경로 - 주 공정 내의 작업이 지연되면, 프로젝트 전체 기간이 늘어나게 됨 주공정 연쇄법 (Critical chain method) - CPM과 유사, 자원제약을 고려하고, 여유시간을 관리 한다는 점에서 차이 - 자원을 고려하여 만들어서 주요경로를 Critical chain이라 함 - Critical chain에 필요한 자원이 준비되지 못하면 결과적으로 프로젝트 지연 자원 평준화 (Resource leveling) - Critical path 작업 후 특정 기간에 자원이 과부화된 경우에 과부화된 자원이 담당하고 있는 업무를 연기하거나 재할당 하는 방법 - 대부분의 변경이 Resource leveling에서 발생함 가정 시나리오 분석 (What-if scenario analysis) - 프로젝트 미래에 대한 예측이 포함 - 예측 가능한 상황을 미리 고려하여 문제를 최소화 하는 방법 일정 단축 (Schedule compression) Crashing 자원을 추가 투입하여 일정 단축하는 방법. 반드시 일정이 단축되지는 않음. 비용은 증가하고, 불확실성 발생 가능 Fast tracking 순차적으로 진행해야 하는 단계/활동을 병행 진행하는 방법으로 실패 시 재 작업 해야 함 Fast tracking는 위험증가 측면이 크고 Crashing은 원가증가 측면이 큼

Ⅳ. 프로젝트 일정 관리시 고려 사항 가. 실현 가능한 일정 추정 나. 범위 관리의 WBS를 근거로 Activity 도출 다. 범위, 일정, 원가는 통합되어 측정되어야함

리스크관리를 위한 의사결정기법 EMV의 개요 가. EMV(Expected Monetary Value)의 개념
프로젝트의 위험요소인 각 위험사건에 대해 사건이 발생할 수 있는 발생확률의 영향 정도에 미치게 되는 손익의 정도 나. EMV의 표현식 1) 위험 사건 현황(Risk Event Status) = 위험 확률 X 발생된 영향의 정도(Amount at Stake) = 금전적 기댓값(EMV : Expected Monetary Value) 2) 기회의 EMV는 양수로 표현하고 리스크는 음수 값으로 표현 3) EMV(기대화폐가치) = SUM(예상 결과의 값 X 발생확률)
EMV의 산출값 문제) 하도급업체가 1억 원의 물품을 두 달 후에 납품하기로 하였고 두 달 후에 납품하지 못할 확률은 50%이며, 우리 회사는 2천만 원 보험에 가입된 상태임 가. 물품 납품에 대한 문제 이해
성과 표(payoff table)

구분 납품함 납품하지 못함 기댓값 1억 원 물품기대 1억 원 물품 리스크 2천만 원 보험 확률 50%(납품할 확률) 50%(납품하지 못할 확률)

나. 물품 납품에 대한 EMV - 납품한 경우 : 0.5 X 1억 원 = 5천만 원 - 납품하지 못할 경우 : 0.5 X 2천만 원(보험) + 0.5 X (-1억 원) = -4천만 원 - EMV = 5천만 원 - 4천만 원 = 1천만 원 3. 프로젝트의 정량적 리스크관리 유사기법 비교

항목 개념 특징 민감도 분석 다른 위험 수치는 고정시킨 상태에서 임의의 한 위험을 한 단위 변동시켰을 때 프로젝트에 미치는 영향력이 어떻게 변동하는지 분석 프로젝트에 가장 많은 영향을 미칠 리스크 판별 가능 의사결정나무 분석 의사결정규칙(decision rule)을 나무구조로 도표화 하여 분류(classification)와 예측(prediction)을 수행하는 정량적 리스크 분석방법 모든 보상 및 후속 결정이 정량화되는 경우 각 대안에 대한 EMV를 구할 수 있음 모의실험 컴퓨터상에서 난수표를 생성해 여러개의 모의 프로젝트를 수행하는 방법 몬테카를로 기법을 사용 EMV 발생할 수도 있고 발생하지 않을 수도 있는 시나리오가 미래에 포함될 때 평균결과를 계산하는 방법 의사결정나무 분석에 사용 원가 및 일정 리스크 분석에 활용 ※ 몬테카를로 - 시뮬레이션 테크닉의 일종으로 구하고자 하는 수치의 확률적 분포를 반복 가능한 실험의 통계로부터 해를 구하는 방법 - 난수생성기를 이용하여 예측과 추정, 그리고 리스크 분석에 유용하게 사용하며, 불확실한 변수에 대해서 미리 세워놓은 모델을 적용하여 여러 시나리오에 대한 계산 작업을 수행하는 과정 ※ 의사결정나무분석(decision tree analysis) : 선택 가능한 대안 별로 발생 가능성과 파급효과를 정량적으로 종합하여 최적의 의사결정을 내리기 위한 기법

※ 민감도 분석(sensitivity analysis) - 다양한 입력변수의 변화에 의해, 수치 모델의 결과 값이 어떻게 달라지는지 지를 살펴보는 분석 - 의사결정나무분석에서 변동구간이 필요할 경우 사용(ex : 호황일 때 수익의 규모 변동, 호황일 가능성, 기존 공장 개선비용) - 토네이도다이어그램(tornado diagram) : 위험도가 큰 변수와 상대적으로 위험도가 낮은 변수가 결과에 미치는 영향을 비교하기 위한 도표 - 양방향 분석 : 결과에 영향을 미치는 두 가지 인자의 종합적 영향을 고려하기 위한 방법, 민감도를 일 방향으로 분석하면 영향을 많이 미치는 인자를 찾아낼 수는 있으나, 다른 인자가 조금 변동 할 경우 다른 인자들의 분석 결과가 판이하게 달라질 수도 있기 때문에 복합적으로 조사를 해 보는 것이다.

프로젝트 성과를 극대화 하기 위한 인적자원관리 프로세스 개요 가. 인적자원관리의 개념
프로젝트 팀을 구성 및 관리하고, 프로젝트 팀을 이끄는 프로세스 나. 인적자원관리의 프로세스

프로세스 내용 산출물 인적자원 계획서 개발 책임과 역할, 보고체계, 인적자원 스킬, 직원관리 계획서를 정의 RACI차트 프로젝트 팀 확보 필요한 인적자원의 가용 여부를 확인한 후 프로젝트에 투입 팀원 배정 프로젝트 팀 개발 프로젝트 성과 향상을 위해 개인의 역량, 팀 상호작용 역량을 향상 성과 평가 프로젝트 팀 관리 개인과 프로젝트의 성과를 분석해서 적절한 피드백을 제공하고 필요한 경우 이슈나 갈등을 조성 갈등관리, 동기부여 2. 역할과 책임의 명확화를 위한 도구, RACI 차트 가. RACI차트의 개념 - 업무 프로세스 상의 부서/개인간 업무에 대한 역할과 책임 및 권한을 명확히 설정하는 표 나. RACI차트의 구성요소

구성요소 설명 R - Responsible(실무담당자) - 해당 업무를 실제로 수행하는 주체 A - Accountable(의사결정권자) - 해당 업무에 대해 최종 책임을 지는 주체 C - Consulted(업무수행 조언자) - 업무 수행과 관련하여 상의가 필요한 주체 I - Informed(결과보고 대상자) - 해당 업무 수행 결과를 통보 받는 주체 다. RACI차트 사례

누가(Who), 어떤 일(What)을 하는지를 명확히 규명함으로써, 구성원간의 유기적 협력체계를 구축하여 효율적 업무 수행을 제고
프로젝트 팀 관리를 위한 프로젝트 갈등 해결 기법 가. 프로젝트 갈등원인

갈등원인 설명 일정 일정에 대한 팀원의 커미트먼트가 부족시 갈등 발생 프로젝트 우선순위 자원할당, 위험관리 등에서 발생하는 프로젝트 우선순위에 대한 이견에 대한 갈등 자원 조직 차원만이 아니라 프로젝트에서도 우수한 혹은 한정된 인적자원을 서로 차지하려는 갈등 기술적 옵션 기술적 방법이 다를 때 갈등 발생 관리 절차 - 관리 절차나 문서작업 때문에 갈등 발생 - 팀원이 불필요하다고 생각하는 문서작업은 대표적인 갈등 원인 원가 프로젝트 경비 부족, 사용방법 때문에 갈등 발생 대인관계 팀원의 성격 차이에 대인관계에서 갈등 발생

나. 프로젝트 갈등원인 해결전략

전략 내용 Forcing - 자기의견 관철 - 긴급하게 결정해야 할 경우 - 옳다고 믿는 주요 안건을 집행할 때 Problem Solving - 문제해결 - 매우 중요한 통합된 의견을 도출할 때 - 공감대를 형성해서 지속적인 관계유지가 필요할 때 Compromising - 양쪽 의견 절충 - 목표는 중요하나 더 이상 설득이 힘들다고 느낄 때 - 복잡한 문제의 잠정적인 해결책을 도출할 때 Withdrawing - 회피 - 이슈가 사소할 때 - 자기의 의견을 관철할 가능성이 낮다고 판단할 때 Smoothing - 상대의견 수용 - 자기의 의견이 틀렸다고 느끼고 자신이 합리성이 있음을 보여줄 때 - 조화와 안정성이 매우 중요할 때

목표를 향한 자발적인 행동유발을 위한, 동기부여 이론
조직원들이 어떤 욕구나 보상에 의해 어떠한 행동을 보이고, 그 성과는 어떠한가를 분석하는 이론 가. 내용(Content) 이론
어떤 행동이 일어나기 전의 초기 단계에서 그 행동을 하게 된 동기를 이끌어 내는 ‘욕구가 무엇(what)이냐’를 다루는 이론

이론 내용 매슬로의 욕구 5단계 이론 - 욕구를 다섯 단계로 나누어 하위 욕구가 충족될 때 상위 욕구를 추구한다는 내용 - 생리적욕구 < 안전욕구 < 사회적욕구 < 존경욕구 < 자아실현 욕구 엘더퍼의 ERG 이론 - 매슬로의 욕구를 존재(existence), 관계(relations), 성장(growth)등 세 가지 유형으로 분류 - 어떤 욕구를 채우지 못하면 그 하위 욕구가 증가 허즈버그의 2요인 이론 - 불만을 야기하는 요인과 만족을 유발하는 요인은 다르다는 점, 불만족을 유발하는 원인을 제거한다고 해서 만족 상태로 가지 않음 - 위생요인(hygiene factor) : 제공되지 않을 경우 불만족이 생기는 요인, 임금, 통제, 작업환경 등 - 동기요인(motivator) : 제공될 경우 만족이 생기는 요인, 책임감, 존경, 자아성취 등 맥클러랜드의 세가지 욕구 이론 - 매슬로의 다섯 가지 욕구중 상위 욕구만 세 범주로 나눔 - 성취 욕구(Need for achievement), 친교욕구(Need for affiliation), 권력욕구(Need for power) 맥그리거의 X이론 Y이론 - 사람의 기질을 X형과 Y형으로 구분하여 어떤 기질이 많느냐로 판단 - X이론 : 소극적, 수동적, 타율적, 비창의적 - Y이론 : 적극적, 능동적, 자율적, 창의적

나. 과정(Process) 이론 - 행동이 일어나는 중간 단계에서 ‘어떻게 그 행동을 할 수 있는 동기를 이끌어내느냐’를 다루는 이론

이론 내용 기대이론 (Expectancy theory) - 노력을 해서 성과가 나올수록 개인의 업무성과가 보상으로 이어질수록 그 보상이 개인을 만족시킬 때 동기 부여됨 - 동기부여(M) >= 가치의 크기(V) × 달성의 가능성(E) 공정성 이론 (Equity theory) - 공정한 평가와 보상이 이루어진다는 인식을 주어야만 동기부여가 가능함 - 조직이 공정성을 실천해서 구성원들을 동기 부여함 - 배분적 공정성, 과정적 공정성, 관계적 공정성 리더십 이론 - 리더십은 비전, 목표를 달성하도록 개인, 집단에게 영향력을 발휘할 수 있는 능력 - 리더의 특성과 자질, 리더의 행동 연구, 상황 이론, 현대적 리더십

웹 상에서 데이터 표현을 위한 JSON의 개요 가. JSON(JavaScript Object Notation)의 개념
인터넷에서 자료를 주고 받을 때 그 자료를 표현하는 방법으로, 문자열화 된 데이터를 객체화하는 경량의 데이터 교환 형식 나. JSON의 특징 1) 경량의 데이터 교환 포맷 2) JavaScript의 구문 형식을 준수 3) 프로그래밍언어나 플랫폼에 독립적
JSON의 문법 및 장단점 가. JSON의 문법

항목 설명 문법개요 - 자바스크립트 표준인 ECMA-262 3판의 객체 문법에 바탕 - 유니코드 인코딩 - 표현 자료형은 수, 문자열, 참/거짓, 배열, 객체 구조 - name/value 쌍으로 구성 - {로 시작하고 }로 끝남 - 배열은 대괄호[]로 나타냄 - 각각의 이름은 : 와 , 로 구분된 name/value쌍의 형식을 다름 사용 예 {"product":"pencil","price":1000} { "이름": "홍길동", "나이": 30, "성별": "남", } 도구 - Parser : JSON text파일을 해석하고 자바오브젝트로 변환 - Renderer : 자바를 text로 표현 - Serializer : POJO를 JSON표현으로 직렬화 - Mapper : POJO와 JSON을 매핑 - Validator : JSON스키마를 이용해서 파일내용 유효성 체크

나. JSON의 장단점

장점 단점 - XML보다 가볍고 빠름 - XML데이터에 자료종류에 큰 제한이 없음 - XML은 모두 string, JSON은 string, number, array, Boolean - JavaScript코드 안에서 JSON 객체에 접근이 쉬움 - eval()로 객체화시 악성코드 유입 취약점 - 태그가 없어 가독성이 떨어짐 - DTD 같은 것이 없기 때문에 데이터 형식이 틀렸을 경우에 체크가 쉽지 않음

JSON 선택 시 고려사항 가. 값을 얻어오기에는 XML보다 JSON이 더 편하고, 속도도 JSON이 좀더 빠름 나. 하지만 복잡한 데이터를 표현 할 때는 XML이 더 편함 다. JSON은 표준이 아니기에 라이브러리가 필요함 라. JSON이 자바스크립트에서는 XML보다 장점이 많으나 그 외 언어에서는 장점이 무효화 되고 호환성 확보가 어려움 마. Ajax 기반 프로그래밍 시 XML을 DOM트리를 통해 데이터에 접근하는 것보다 동일한 구조를 갖는 JavaScript객체로서 다루는 것이 편리함

SW사업 대가산정 가이드 개요 가. SW사업 대가산정 가이드 목적
소프트웨어의 기획, 구현, 운영 등 수명주기 전 단계에 대한 사업을 추진함에 있어 이에 대한 예산수립, 사업발주, 계약시 적정대가를 산정하기 위한 기준을 제공
국내 SW사업의 품질을 향상시키고 제값주기 환경을 지속 정착시켜 SW산업의 경쟁력을 제고
SW산업의 동적인 상황과 글로벌 표준에 입각한 ISO12207 기반의 소프트웨어의 수명주기(기획, 구현, 유지보수·운영) 전반에 걸쳐 대가산정 방법을 알기 쉽게 설명하고, 보다 편리하게 수행할 수 있는 도구를 제공 나. SW사업 대가산정 가이드 등장배경
SW사업 대가산정 가이드 선정 프레임워크 가. SW사업 대가 산정 모형 선정 프레임워크
SW사업 대가 산정 모형은 1)사업유형 식별, 2)대가산정 시점 식별, 3)대가산정 모형 선정의 3단계 절차에 따라 선정됨 나. SW사업 대가 산정 모형 선정 프레임워크 구성요소

항목 구성요소 설명 수명주기 기획단계 SW사업 수명주기 상의 기획단계에 해당하는 사업으로서, IT컨설팅 사업이 해당 구현단계 SW사업 수명주기 상의 구현단계에 해당하는 사업으로서, 소프트웨어 개발사업이 이에 해당 운영단계 SW사업 수명주기 상의 운영단계에 해당하는 사업 대가산정 시점 예산확보 단계 SW사업의 예산을 확보하기 위해 사업비를 개괄적으로 산정하는 단계 사업발주 단계 SW사업을 발주하기 위해 제안요청서 등을 작성하고, 발주금액을 산정하는 단계 사후정산 단계 SW사업이 종료된 후에 실제 투입된 사업비와 집행된 사업비의 차이를 파악하여 필요시 정산을 위한 대가를 산정하는 단계

SW사업 대가산정 가이드 적용 범위
대가산정의 대상이 되는 사업의 유형과 대가산정 시점에 따라 적절한 모형을 선택하여 적용

△ : 예산확보 단계 및 사업발주 단계에 사업비를 산정하기 위해 직접 적용되지 않으나 사전에 사후 정산의 가능성을 고려해야 함 나. 대가산정 요소별 비용 구성

대가산정 요소 비용 구성 컨설팅 지수 1) 컨설팅대가 = 공수 x (컨설팅지수)0.95 + 10,000,000 2) 직접경비 투입공수 1) 직접인건비 2) 제경비 = 직접인건비의 110% - 120% 3) 기술료 = (직접인건비 + 제경비)의 20% - 40% 4) 직접경비 기능점수 1) 개발원가 2) 제경비 = 직접인건비의 110% - 120% 3) 직접경비 유지보수 총점수 1) 소프트웨어 개발비 재산정가 × 유지보수 난이도(%) 2) 직접경비 기능점수, 투입공수 1) 변동비 산정(재개발대가) 2) 고정비 산정(투입공수방식 운영비) 3) 직접경비 서비스 항목, 보상/제재 비율 1) 서비스 측정 2) 서비스 평가 3) 보상/제재 비율에 따른 사후정산 재개발 기능점수 1) 재개발원가 2) 이윤 = 재개발원가 x 25% 이내 3) 직접경비

기존 대가기준과 비교하여 SW사업 대가산정 가이드의 차별성 가. 절차 중심 설명
가이드의 문장 기술 방식을 기존의 조문별 해설 방식에서 사용자 친화적인 절차 중심의 설명 방식으로 개선하여 사용자 관점에서의 이해도 향상 나. 수명주기 단계별 산정방식
SW사업 수명주기(기획단계, 구현단계, 운영단계) 단계별 특성을 고려하여 사용자의 주요 업무단계에 따라 대가산정 방식을 설명하는 체계로 개선하여 현장 적용성을 향상 다. 예제 및 사례 추가
각 업무단계별 예제 및 복합적 소프트웨어유형을 포함하는 대가산정 사례를 추가하는 등 사례 중심의 내용으로 실무 적용성과 이해도 향상 라. 컨설팅 사업영역 추가
여러 유형의 IT컨설팅 사업영역을 추가하고, 유지보수 및 운영사업의 대가산정 모형을 보완 확장 마. DB구축비 및 시스템운용환경 구축비 삭제
행정안전부 한국정보화진흥원에서 별도 공고된 DB구축비 대가기준 가이드와 엔지니어링 사업 대가의 기준, 정보통신 표준품셈 등으로 대체 가능한 DB구축비 및 시스템운용환경 구축비 산정기준은 삭제

소프트웨어 재사용 극대화를 위한 디자인 패턴의 개념 가. 디자인 패턴의 정의
객체지향 설계에서 자주 반복되며 유용한 구조 및 경험을 정리하여 일정한 형식으로 저장한 패턴 나. 디자인 패턴의 장∙단점

역할 장점 단점 설계 고품질의 설계가능 오용된 패턴은 유지보수를 더 어렵게 만들 수 있음 개발 시스템 개발 시 공통 언어 역할 잘못 해석된 패턴은 재사용성을 더 어렵게 만들 수 있음 운영 향후 변화에 대한 대비 잘못 사용된 패턴은 개발을 더 어렵게 만들 수 있음 유지보수 용이성 설계자가 패턴을 익히는데 오랜 훈련시간을 필요로 함

신속성 제공 : 기 개발자의 설계 노하우 재사용
품질 제공 : 전문가 노하우 이용 좋은 SW 설계, 확장성 및 유지보수성 제공
디자인 패턴의 구성요소 및 종류 가. 디자인 패턴의 구성요소

구성요소 내용 패턴의 이름과 구분 패턴을 부를때 사용하는 이름과 패턴의 유형 문제 및 배경 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미 솔루션 패턴을 이루는 요소들, 관계, 협동 과정 사례 간단한 적용 사례 결과 패턴을 사용하면 얻게 되는 이점이나 영향 샘플코드 패턴이 적용된 소스코드

나. 디자인 패턴의 종류

생성 유형 : 객체를 생성하는 패턴
구조적 유형 : 클래스와 객체가 어떤식으로 조합되었는지를 나타내는 유형
행위적 유형 : 객체의 상호작용과 의무의 분산
디자인 패턴 문제 해결 순서 가. 적절한 객체를 찾음 나. 아주 작고 쉬운 문제가 아닌 어느 정도의 난해한 추상적 개념을 지닌 부분을 찾아 이를 표현할 객체를 파악 다. 객체의 규모를 파악 라. 객체의 인터페이스를 작성하되 유사 클래스를 가진 클래스를 지정하여야 하며 인터페이스에 대한 제한 조건을 설정 마. 디자인 패턴을 사용하여 객체의 구현을 작성할 때는 클래스의 상속을 할 것인지 인터페이스 상속을 이용할 것인지 구별하며 재사용 메커니즘도 여러 가지 유형 중에서 선택
디자인 패턴 적용 시 유의사항(원칙)

원칙 내용 구현(Implementation) 클래스가 아니라 인터페이스(Interface) 사용 인터페이스 클래스의 메서드 호출 인터페이스를 구현한 클래스의 내부 변화에 독립적임 상속(Inheritance)이 아니라 위임(Delegation) 사용 상속의 경우 컴파일시 슈퍼클래스와 서브클래스의 관계가 결정되나 위임의 경우 런타임 단계에서 클래스이용 커플링(Coupling) 최소화 한 클래스의 변화가 전체 클래스에 영향을 주지 못하도록 설계해야 함

디자인 패턴과 아키텍처 스타일의 비교

구분 디자인패턴 아키텍처 스타일 정의 개발자의 경험에 의한 문제영역의 해결책에 대한 객체들간의 상호작용 방법을 모은 목록 시스템 및 조직의 관점에서 시스템 구조에 초점을 맞춘 상위 수준의 설계 지침 관점 개발자의 구현 관점 경험기반의 모델링 조직적 구성 관점 경험기반의 아키텍처 구성 특징 - 단순화, 이해용이성 - 분석과 설계에 대한 추상적인 관점 제공 - 개발자가 이해하고 적용할 수 있는 형태로 제공 - 확장성, 재사용성, 이해용이성 등 제공 - 아키텍처의 품질요소를 개선 - 기능적 컴포넌트를 변경하고 확장 시키는데 초점 - 동일한 기능을 수행하는 또 다른 아키텍처 구성 패턴 사용의 제약 대표적 종류 Adapter Pattern Factory Pattern Command Pattern Interpreter Pattern Façade Pattern Builder Pattern 분산스타일 파이프와 필터 스타일 데이터 중심 스타일 규칙기반 스타일 블래보드 스타일 레이어 스타일

GOF(Gang Of Four) 생성패턴 Factory Method Pattern의 개요 가. Factory Method Pattern의 정의
객체를 생성하기 위한 인터페이스를 따로 정의하고 그 인터페이스를 정의한 Class를 상속(구현)한 Class에서 생성될 구체적인 객체를 정의
객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정하게 만들고 팩토리 메시지도 패턴을 이용하여 클래스의 인스턴스를 만드는 일을 서브클래스에 위임 나. Factory Method Pattern의 적용영역
객체들에 대한 클래스의 종류를 예상할 수 없을 때
생성할 객체를 기술하는 책임을 서브 클래스에 정의하고자 하는 경우
객체 생성의 책임을 서브 클래스에게 위임시키고 서브 클래스에 대한 정보를 은닉하고자 할 경우 다. Factory Method Pattern의 장‧단점
장점 : 구현이 쉽기 때문에 완전한 Abstract Factory가 과잉 솔루션일 때 도입하기 좋음
단점 => 구현 상속을 강제로 사용하도록 강제하기 때문에 유지보수에 문제가 있음 => 구현 상속 기반의 프레임워크 아키텍처에서 Factory Method가 자주 발견되는데 이방법이 재사용을 위한 최선의 방법이 아님 라. Factory Method Pattern 원칙
추상화된 것에 의존하도록 만들고, 구상 클래스에 의존하도록 만들지 않음
다른 말로는"의존성 뒤집기 원칙(Dependency Inversion Principle)" 이라고 함
의존성 뒤집기 원칙에서는 추상화를 강조하며, 이 원칙은 고수준의 구성요소가 저수준 구성요소에 의존하면 안된다는 것을 내포하고 있음
Factory Method Pattern의 다이어그램
Creator : 실제 타입이 알려지지 않은 객체를 생성할 필요가 있는 메서드를 정의, 추상메서드 호출을 통해 수행
ConcreteCreator : Creator의 객체 생성 추상 메서드를 오버라이드하여 ConcreteProduct를 생성하는 파생 클래스
Product : 생성되는 객체가 구현하는 인터페이스, Creator는 이 인터페이스를 통해 ConcreteProduct에 접근
ConcreteProduct : Creator(기반 클래스) 메서드에 사용되는 객체, Product 인터페이스를 구현
Factory Method Pattern 예제 가. 예제코드

enum PIZZA_TYPE { PIZZA_TYPE_NONE = 0, PIZZA_TYPE_CHEESE, PIZZA_TYPE_PEPPERONI, };

class Pizza { public: void Bake( void ) {} void Cut( void ) {} void Box( void ) {} void ShowName( void ) { cout<<m_szName<<endl; }

public: std::string m_szName; };

class MrPizzaStyleCheese : public Pizza { public: MrPizzaStyleCheese( void ) { m_szName = "미스터피자 : 치즈"; } };

class MrPizzaStylePepperoni : public Pizza { public: MrPizzaStylePepperoni( void ) { m_szName = "미스터피자 : 패패로니"; } };

class DominosPizzaStyleCheese : public Pizza { public: DominosPizzaStyleCheese( void ) { m_szName = "도미노피자 : 치즈"; } }; class DominosPizzaStylePepperoni : public Pizza { public: DominosPizzaStylePepperoni( void ) { m_szName = "도미노피자 : 패패로니"; } };

class PizzaStore { public: virtual Pizza* CreatePizza( PIZZA_TYPE ) = 0;

public: Pizza OrderPizza( PIZZA_TYPE eType ) { Pizza pOrderPizza = CreatePizza( eType ); pOrderPizza->Bake(); pOrderPizza->Cut(); pOrderPizza->Box(); return pOrderPizza; } };

class MrPizzaStore : public PizzaStore { public: virtual Pizza* CreatePizza( PIZZA_TYPE eType ) { switch( eType ) { case PIZZA_TYPE_CHEESE: { return new MrPizzaStyleCheese; }break;

    case PIZZA_TYPE_PEPPERONI:
        {
            return new MrPizzaStylePepperoni;
        }break;
    }
}

};

class DominosPizzaStore : public PizzaStore { public: virtual Pizza* CreatePizza( PIZZA_TYPE eType ) { switch( eType ) { case PIZZA_TYPE_CHEESE: { return new DominosPizzaStyleCheese; }break;

    case PIZZA_TYPE_PEPPERONI:
        {
            return new DominosPizzaStylePepperoni;
        }break;
    }
}

};

int _tmain(int argc, _TCHAR argv[]) { PizzaStore pDominosPizzaStore = new DominosPizzaStore; Pizza* pDominosPizza = pDominosPizzaStore->OrderPizza( PIZZA_TYPE_CHEESE ); pDominosPizza->ShowName();

PizzaStore* pMrPizzaStore = new MrPizzaStore;
Pizza* MrPizza = pMrPizzaStore->OrderPizza( PIZZA_TYPE_PEPPERONI );
MrPizza->ShowName();

cout<<endl;

}

나. 결과화면

위의 예제코드 다이어그램
Factory Method Pattern 구현 시 고려사항 가. Factory Method Pattern은 생성할 객체의 종료가 많아질수록 그 만큼의 하위 클래스를 정의해야 한다는 단점 나. 단점 보완 방법으로는 생성하는 클래스는 한 종류로 생성하고, 생성할 객체의 종류는 Prototype Pattern을 이용하여 결정 ※ 프로토타입 패턴(Prototype Pattern) : 복제 생성 인터페이스를 노출시켜 기존의 객체를 복제하는 방식으로 새로운 객체를 생성하는 패턴
Factory 패턴의 특징 및 관련 패턴 가. Factory 패턴의 특징

특징 내용 코드 최적화 객체 생성코드를 하나의 method로 정의함으로 코드중복을 제거 객체 생성의 유연성 객체 생성시 인터페이스를 바탕으로 하기 때문에 유연성, 확장성 뛰어난 코드 생성 하위 클래스 문제 생생할 객체의 종류가 달라질 때마다 새로운 하위 클래스 정의 필요

나. Factory 패턴과 관련 패턴

패턴 관련 내용 Template Method Factory Method 패턴은 Template Method 패턴의 전형적인 응용 Singleton Creator역할을 수행하는 클래스는 대부분Singleton패턴 Composite Product 역할에 Composite패턴을 적용 할 수 있음 Iterator Iterator패턴에서 Iterator method가 iterator의 인스턴스를 작성시 Factory method사용하는 경우 있음

※ composite 패턴 파일이나 폴더의 정보를 표시하는 소프트웨어를 만들려고 한다. 폴더 안에는 일반적으로 여러개의 파일이 들어 있고 폴더 속에는 또 다른 폴더인 서브 폴더가 들어 있을 수 있는 재귀적인 구조를 가지고 있으므로 데이터를 동일하게 다루기 위해 클래스를 아래와 같이 구성하였다

다. Factory 패턴과 Abstract Factory 패턴의 비교

종류 Factory Method Pattern Abstract Factory Pattern 목적 객체 생성에 대한 기능을 서브 클래스로 분리 관련성을 가지는 객체의 집합을 생성하는 인터페이스를 제공 특징 - 클래스의 기능적인 분리 및 캡슐화. - 공통 인터페이스로 클래스들의 일괄적 관리가 가능. - 연관된 제품 및 제품군 생성 - 무분별하게 상용시 자체로 코드의 가독성 떨어짐 방법 클래스의 상속을 통하여 객체 생성 객체 구성을 통해서 생성.

구현이 아닌 인터페이스에 맞춰서 프로그래밍하는 Strategy Pattern의 개요 가. 스트래티지 패턴(Strategy Pattern)의 정의
애플리케이션에서 달라지는 부분을 찾아내고 달라지지 않는 부분은 분리 시켜서 캡슐화하는 패턴
실행도중 행동을 바꿀 수 있는 장점 때문에 상속보다 구성을 활용 나. Strategy Pattern의 특징
바뀌지 않는 부분에는 영향을 미치지 않으면서 바뀌는 부분만 고치거나 확장 가능
바뀌는 부분의 클래스 집합을 유연성있게 디자인 하고 행동들을 동적으로 바꿀수 있음(세터 메서드)
Strategy Pattern의 다이어그램
Strategy : Strategy는 전략을 이용하기 위한 인터페이스
ConcreteStrategy : 여기에 구체적인 전략을 실제로 프로그래밍
Context : Strategy를 이용하는 역할, ConcreteStrategy의 인스턴스를 가지고 있으며 필요에 따라 그것을 이용
Strategy Pattern의 예제 가. 예제코드

class FlyBehavior { public: virtual void Fly( void ) = 0; };

class FlyWithWings : public FlyBehavior { public: virtual void Fly( void ) { cout<<"날고 있어요."; } };

class FlyNoWay : public FlyBehavior { virtual void Fly( void ) { cout<<"저는 못날아요."; } };

class QuackBehavior { public: virtual void Quack( void ) = 0; };

class SoundQuack : public QuackBehavior { public: virtual void Quack( void ) { cout<<" '꽥꽥꽥' "<<endl; } };

class MuteQuack : public QuackBehavior { public: virtual void Quack( void ) { cout<<" 조용~ "<<endl; } };

class Duck { public: void PerformFly( void ) { m_pFlyBehavior->Fly(); } void PerformQuack( void ) { m_pQuackBehavior->Quack(); }

void    SetFlyBehavior( FlyBehavior* pFly ) { m_pFlyBehavior = pFly; }
void    SetQuackBehavior( QuackBehavior* pQuack ) { m_pQuackBehavior = pQuack; }

public: FlyBehavior m_pFlyBehavior; QuackBehavior m_pQuackBehavior; };

int _tmain(int argc, _TCHAR argv[]) { Duck pModel = new Duck;

cout<<"행동0 : ";
pModel->SetFlyBehavior( new FlyWithWings );
pModel->SetQuackBehavior( new SoundQuack );
pModel->PerformFly();
pModel->PerformQuack();

cout<<"행동1 : ";
pModel->SetFlyBehavior( new FlyNoWay );
pModel->SetQuackBehavior( new MuteQuack );
pModel->PerformFly();
pModel->PerformQuack();

cout<<endl;

}

나. 결과화면

위의 예제코드 다이어그램으로 표시 가. 예제코드 다이어그램 1

나. 예제코드 다이어그램 2

다형적인 형식을 사용하는 간단한 예
Animal 이라는 추상클래스가 있고 그 밑에 Dog와 Cat이라는 구상클래스가 있다고 가정 가. 구현에 맞춰서 프로그래밍 할 경우

Dog d = new Dog(); d.bark()

변수 “d”를 Dog형식(Animal을 확장한 구상클래스)으로 선언하면 어떤 구체적인 구현에 맞춰서 코딩해야 함 나. 인터페이스에 맞춰서 프로그래밍 할 경우

Animal animal = new Dog(); animal.makeSound();

Dog라는 걸 알고 있긴 하지만 다형성을 활용하여 Animal에 대한 레퍼런스를 사용
상속보다는 구성을 활용(“A는 B이다” 보다 "A에는 B가 있다"가 나을 수 있다) 가. 구성이란 “A에는 B가 있다” 라는 관계로 설명할 수 있으며 상위 클래스에서 여러개의 인터페이스 형식의 인스턴스변수를 추가하여 합치는 것을 구성(composition)을 이용하는 것 이라고 함 나. 구성은 단순히 알고리즘군을 별도의 클래스의 집합으로 캡슐화할 수 있도록 만들어주는 것 뿐 아니라 구성요소로 사용하는 객체에서 올바른 행동 인터페이스를 구현하기만 하면 실행시에 행동을 바꿀 수도 있게 해줌

상태 변화에 따른 처리를 기술할 때 효과적인 Observer Pattern의 개요 가. 옵저버 패턴(Observer Pattern)의 정의
관찰 대상의 상태가 변화하면 관찰자에게 알려주는 패턴
한 객체의 상태가 바꾸면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다( one-to-many) 의존성을 가지는 패턴
Observer(옵저버)는 subject(주제)에 의존하며, subject(주제)의 상태가 바뀌면 옵저버한테 연락이 가게되며, 서로 상호작용을 하지만 서로에 대해서는 전혀 알지 못함 나. 옵저버 패턴의 특징
느슨한 결합(Loose coupling)을 제공 : 옵저버는 구상클래스가 무엇인지, 옵저버가 무슨일을 하는지 알 필요가 없음
새로운 형식의 observer(옵저버)를 추가하려고 할 때도 subject(주제)를 전혀 변경할 필요가 없음
subject와 observer는 서로 독립적 : subject(주제)나 observer(옵저버)가 바뀌더라도 서로한테 영향을 미치지 않음(서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용)
옵저버 패턴의 다이어그램
ConcreteSubject에 Get, Set있다면 ConcreteObserver는 ConcreteSubject를 "A에는 B가있다"로 표시(즉 Observer인 동시에 Subject의 역할을 함)
subject : 변경되는 데이터가 존재
observer : 데이터를 받아 갱신되는 쪽
subject(주제)와 observer(옵저버)는 일대다 관계를 정의
observer Pattern 예제코드 가. 예제코드

class Observer { public: virtual void Update( float fData0, float fData1, float fData2 ) = 0;

public: std::string m_szName; };

class Subject { public: virtual void RegisterObserver( Observer pO ) = 0; virtual void RemoveObserver( Observer pO ) = 0; virtual void NotifyObservers( void ) = 0; };

class WeatherData : public Subject { public: virtual void RegisterObserver( Observer pO ) { m_map_Observers.insert( STL_MAP_OBSERVERS_VT( pO->m_szName, pO ) ); } virtual void RemoveObserver( Observer pO ) { m_map_Observers.erase( pO->m_szName ); } virtual void NotifyObservers( void ) { STL_MAP_OBSERVERS_ITR Itr = m_map_Observers.begin(); while( Itr != m_map_Observers.end() ) { Observer* pObserver = Itr->second; pObserver->Update( m_fData0, m_fData1, m_fData2 ); ++Itr; } }

public: float GetData0( void ) { return m_fData0; } float GetData1( void ) { return m_fData1; } float GetData2( void ) { return m_fData2; } void SetData( float fData0, float fData1, float fData2 ) { m_fData0 = fData0; m_fData1 = fData1; m_fData2 = fData2; NotifyObservers(); }

private: float m_fData0; float m_fData1; float m_fData2;

private: typedef std::map< std::string, Observer* > STL_MAP_OBSERVERS; typedef STL_MAP_OBSERVERS::iterator STL_MAP_OBSERVERS_ITR; typedef STL_MAP_OBSERVERS::value_type STL_MAP_OBSERVERS_VT; STL_MAP_OBSERVERS m_map_Observers; };

class ConditionDisplay : public Observer { public: ConditionDisplay( Subject* pSubject ) { pSubject->RegisterObserver( this ); m_pSubject = pSubject; }

public: virtual void Update( float fData0, float fData1, float fData2 ) { m_fData0 = fData0; m_fData1 = fData1; m_fData2 = fData2; } public: void DisPlay( void ) { cout<<"디스플레이 - 온도 : "<<m_fData0<<endl; cout<<"디스플레이 - 습도 : "<<m_fData1<<endl; cout<<"디스플레이 - 압력 : "<<m_fData2<<endl; cout<<endl; }

private: Subject* m_pSubject; float m_fData0; float m_fData1; float m_fData2; };

int _tmain(int argc, _TCHAR argv[]) { WeatherData pWeatherData = new WeatherData; ConditionDisplay* pConditionDiplay = new ConditionDisplay( pWeatherData );

pWeatherData->SetData( 10.5f, 20.5f, 30.5f );
pConditionDiplay->DisPlay();

}

나. 결과화면

위의 예제코드 다이어그램으로 표시

Proxy Pattern의 개요 가. 프록시 패턴(Proxy Pattern)의 정의
어떤 객체에 대한 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴 나. 프록시 패턴 다이어그램
프록시 패턴 예제코드 가. 예제코드

class Image { public: virtual float GetWidth( void ) = 0; virtual float GetHeight( void ) = 0; virtual void Draw( float fX, float fY ) = 0;

protected: string m_szName; };

class ImageIcon : public Image { public: ImageIcon( string szName ) { m_szName = szName; }

public: virtual float GetWidth( void ) { return m_fWidth; } virtual float GetHeight( void ) { return m_fHeight; } virtual void Draw( float fX, float fY ) { cout<<"Draw : "<<fX<<","<<fY<<"위치에 "<<m_szName<<" 아이콘을 그렸어요"<<endl<<endl; }

private: float m_fWidth; float m_fHeight; };

class ImageIconProxy : public Image { public: ImageIconProxy( string szName ) { m_szName = szName; m_pImageIcon = NULL; }

public: virtual float GetWidth( void ) { if( m_pImageIcon ) return m_pImageIcon->GetWidth(); return 32; }

virtual float   GetHeight( void )
{
    if( m_pImageIcon )
        return m_pImageIcon->GetHeight();
    return 32;
}

virtual void    Draw( float fX, float fY )
{
    m_pImageIcon = GetImageFileCache( m_szName );

    if( m_pImageIcon )
        m_pImageIcon->Draw( fX, fY );
    else
    {
        cout<<"[이미지를 로딩중입니다. 잠시만 기다려주세요]"<<endl<<endl;
        m_pImageIcon = LoadImageFile( m_szName );
        m_pImageIcon->Draw( fX, fY );
    }
}

public: Image GetImageFileCache( string szName ) { return NULL; } Image LoadImageFile( string szName ) { return new ImageIcon( szName ); }

private: Image* m_pImageIcon; };

int _tmain(int argc, _TCHAR argv[]) { Image pImageIcon = new ImageIconProxy( "라이푸" ); pImageIcon->Draw( 8, 9 ); return 0; }

나. 결과화면

위의 예제코드 다이어그램으로 표시

객체지향 설계 원칙 5-1 OCP(Open-Close Principle) 개방 폐쇄 원칙 원리 첫번째 원칙인 개방-폐쇄의 원칙이다.무엇을 개방하고 무엇을 폐쇄한다는 것일까 ? 이것을 한마디로 표현하는 말이 있다."Should be Open for Extension, but Closed for Modification" (확장에는 개방하고 수정에는 폐쇄하라)이렇게 말하면 또 이해가 안간다 ㅡㅡ 나는 용어에 참 약하다. 그래서 좋은 예를 하나 훔쳐왔다. 핸드폰 이야기 ...예전에 핸드폰 충전잭은 핸드폰 마다 각기 달랐다 그래서 핸드폰을 새로 구입하면 충전기도 무용지물이 되었다. 그러다 핸드폰 충전잭이 24핀으로 통일 되었다. 그래서 이제는 충전기 하나만 구입하면 핸드폰을 새로 구입해도 그대로 사용할 수 있게 되었다. 그럼 여기서 무엇이 확장이고 무엇이 수정일까 ? 확장은 핸드폰의 종류이다. 어떠한 종류의 핸드폰이라도 24핀 충전기 하나면 OK 이다. 그러면 수정은 무엇일까 ? 수정은 충전핀이다. 이제는 모든 핸드폰의 충전 단자를 24핀으로 만들어야 한다. 좋은 예가 되었나 ? 더 와닿는 예를 생각해 봤는데 ... 쩝 ...방법자 그럼 이제 뜬구름 잡는 얘기는 그만 두고 실제로 적용 방법을 알아보자 먼저 OCP 원칙에 의한 설계를 하려면 변화지 않는것과 변하는것을 최대한 엄격히 구분지어야 한다. (사실 말은 쉽게 하지만 이부분은 정말 어렵고 잘 안되는 부분이다.) 그리고 나서 변하는것을 개방(Open) 하고 변하지 않는것을 Close(폐쇄) 하여야 한다. 이것이 무슨 말이냐 하면 변하는 것에 대해서는 변화하는 것은 변화가 쉽게 유연하게 설계하고 변화 하지 않는것은 변하는 것에 영향을 받지 않도록 설계 해야 한다.그럼 이러한 것들을 유연하게 하려면 도데체 어떻게 해야 하는 것일까 ? 그 답은 추상화와 다형성에 있다.이렇게 말하면 또 와 닿지 않는다. ㅡㅡ 샘플로서 알아보도록 하자.% OCP 를 가장 잘 표현한 패턴은 Command 패턴이다.시나리오스타 크래프트 라는 게임을 모두 알것이다. 게임에서 SCV, 질럿, 저글링 등 모든 유닛들은 마우스로 선택한 다음 이동하려고 하는 목표 지점에 마우스로 선택하면 선택한 지점으로 이동한다. 이 기능을 구현해야 한다고 생각해 보자.먼저 단계를 나누자 1, 유닛 선택: 특정 유닛을 마우스로 선택한다.2, 위치 지정: 유닛이 선택된 상태에서 이동을 원하는 위치로 마우스 클릭 한다.3, 유닉 이동: 각 종류(질럭, SCV, 저글링 등등)의 유닛별로 선택된 위치로 이동한다. 간략하게 그림으로 그려보자

그림으로 보면 일단 마우스로 유닛을 선택하여 다른 위치로 이동 시키는 부분은 모두 동일하다.수정이 불필요한 구간이라는 것이다. 이 구간은 폐쇄(Close)해야 한다. 그러면 유닛이동에서 하단 부분은 개방(Open) 되어있다. 왜 그럴까 ? 그것은 유닛별로 이동 속도가 다르고 지상유닛은 걸어가고 비행유닛은 날라가고 각각 행동이 틀리다.그래서 개방(Open)된 구간에서는 변경이 되어야 하는 구간인 것이다.그러면 개방(Open) 된 부분의 클래스 구성도로 살펴 보자.

간략하게 그려보면 위 그림과 같을 것이다.물론 Move 메소드 이외에 새로운 메소드가 추가로 필요하다면 CUint 클래서도 변경이 되겠지만 일단은유닛이동만 생각하기로 하자.OCP 는 추상화, 다형성이 중요하다고 말한것을 기억하는가 ? 바로 위에 써 놓았다.이것이 바로 추상화와 다형성을 보여주는 간단한 샘풀이다.% C++ 개발자 이면서 아직도 Vitual 키워드를 잘 모른다면 여태까지 객체지향을 제대로 사용하지 않았을 가능성이 높다. 지금이라도 확실히 알고 넘어가길 바란다.결론허접한 설명과 허접한 샘플을 만들어 보았다.다시 정리해 보자면 OCP 에 맞게 설계를 하려면 변하는 것과 변하지 않는것을 먼저 구분하고, 어느 정도까지 추상화 시킬지를 결정해야 한다. 말은 아주 쉽다. ㅡㅡ 그러나 이 간단한 원리를 잘 적용하기 위해서는 많은 경험이 필요하다. 그냥 막 되는대로 코딩의 경험이 필요한것이 아니라 작은 일이라도 먼저 생각해서 설계하는 경험이 중요하다는 말이다. "원칙은 원칙일뿐 현재 상황에서 최선이라고 생각하는 자신만의 원칙을 만들어 가자" 개방-폐쇄의 원칙은 ‘확장에 대해서는 개방되어야 하지만, 변경에 대해서는 폐쇄되어야 하는 원칙’을 의미한다

[그림 1-7] Strategy 패턴 클래스 다이어그램 [그림 1-7]은 Strategy 패턴을 나타내는 클래스 다이어그램이다. 다이어그램에서 Strategy 인터페이스의 하위 클래스로 ProbStrategy와 WinningStrategy클래스를 볼 수 있다. 그리고 Player 클래스와 Strategy 인터페이스가 ‘¼Aggregation’¸으로 연결되어 있기 때문에, Player클래스에서 멤버 변수로서 Strategy인터페이스를 소유하고 있음을 알 수 있다. 이러한 상황에서 새로운 Strategy클래스를 추가하여 기능을 확장하는 것은 무척 자연스럽다. 왜냐하면 실행 시 Player의 멤버 변수를 변경하는 일은 Player 생성자를 실행할 때, 실제 필요한 Strategy객체를 생성하여 매개변수로 전달하면 되기 때문이다. [그림 1-7]에서 새로운 Strategy를 추가한 사례는 [그림1-8]과 같다.

[그림 1-8] RandomStrategy를 추가한 Strategy 패턴 클래스 다이어그램 이러한 구조는 ‘인터페이스의 변경은 닫혀 있으나 인터페이스의 구현은 열려 있다’라고 할 수 있으며, 이것이 바로 개방-폐쇄 원칙이다. 이러한 원칙을 통해 얻고자 하는 것은 기능을 확장했을 때, 기존 클래스의 변경을 최소화할 수 있다는 점이다. 이러한 장점은 디자인 패턴을 적용하는 이유이기도 하다 객체지향 설계 원칙 5-2 LSP (Liskov Substitution Principle) 리스코프 대체 원칙이번에는 리스코프 대체 원칙이다. 이 원칙은 Base-Class 와 Sub-Class 와의 관계에 대한 원칙이다.이것을 먼저 한마디로 표현하면 다음과 같다."기반 타입은 서브타입을 대신 할수 있어야 한다."말로 풀어서 설명하기는 자신이 없다. Exception 클래스를 예제로 설명해 보겠다.

[그림 1] [그림 1] 클 간단한 클래스 구성도 이다. 그럼 이것을 코드로 구현하면 [그림 2]가 된다.

[그림 2] [그림 2] 의 코드에서 try 부분에서 예외가 발생하면 어떻게 되겠는가 ? "int* n = new int;" 는 메모리 생성에 대한 부분이므로 이부분에서 오류가 생기면 MemoryExecption 이 발생한다. 그리고 메모리 관련이외의 예외가 발생하면 CExecptoin 에서 catch 할 것이다. 그럼 [그림 2]의 코드에서 메모리 관련 예외를 catch 하는 부분을 제거 한다면 어떻게 되겠는가 ? 그러면 [그림 3]과 같이 코드가 구성될 것이다.

[그림 3] [그림 3] 코드에서 메모리 관련 예외가 발생하면 어떻게 되겠는가 ? CExecption 이 catch 에서 받아 처리 할것이다. 이 예는 기반타입(CExecption) 이 서브타입(CMemoryExecption) 을 대체하는 좋은 예이다.서브타입을 설계할때 기반타입의 규칙을 잘 이해하여 설계해서 만들어야 하고, 후에 서브타입에 새로운 기능이 추가 될때 이를 기반타입에서도 처리할 수 있어야 한다. 다시말해, 기반 타입은 서브타입의 조건(서브타입의 조건을 포함)보다 더 많은 조건을 처리 할수 있어야 한다.쉽게 그림으로 보면 [그림 4]와 같은 형태과 되어야 한다는 것이다. [그림 4] 그러면 여기서 한가지 의문을 가질수 있다. "서브타입의 모든 기능을 기반타입에서 소화 한다면, 왜 상속을 받아서 서브타입을 설계해야 하는가 ?" 라는 문제이다. 이 답을 하기전에 좋은 말 하나 먼저 들어보자."기반클래스 에서는 서브클래스에서 보다 사전 조건이 더 강해야 하고 사후 조건에서는 서브클래스에서 보다 약해야 한다."무슨 말인지 감이 안온다. 먼저 사전 조건이란 위에서 Execption 의 예로 설명한 조건으로 생각해도 되겟다. CExecptoin 이 CMemoryExecption 보다 더 많은 예외를 잡아 낼수 있다. 이것은 사전 조건이 더 강하다. 라고 이해 하면 되겠다. 그럼 사후 조건에 대해서 한번 살펴 보자.CExecption 과 CMemoryExecption 이 가지고 있는 char* ReportError() 메소드를 살표보자. 먼저 CExecption 의 ReportError 메소드를 호출하면 그 결과가 다음과 같다고 가정하자."[Error Code: 1234] [Error FileName] Test.cpp" 그리고 CMemoryExecptoin 에서 ReportError 메소드를 호출하면 그 결과과 다음과 같다고 가정하자."[Error Code: 1234] [Error FileName] Test.cpp [Error Memory Address] 0x12345678"먼가 느낌이 오는가 ? 안온다면 [Error Memory Address] 부분에 집중해보자. CExecption 의 ReportError 메소드에서 [Error Memory Address] 정보를 보여줄 책임이 있는가 ?그렇지 않다 CExecption 에서는 [Error Memory Address] 대해서 알지 못한다. 그러면 CMemoryExecption 의 ReportError 메소드에서는 [Error Memory Address] 정보를 보여줄 책임이 있는가 ? 맞다. 책임이 있다.이것을 어렵게 말하면 사후조건은 서브클래스(CMemoryExecption )가 기반클래스(CExecption ) 보다 강하다고 한다.개인적으로 5원칙 중에 LSP 가 개념적으로 제일 어렵다. "왜 그럴까 ?" 생각해 봤는데 기존에 알고 사용했던 것과 많이 달라서 인거 같다. 이전에 클래스 상속관계에 대한 가이드는 IS-A 관계였다. 그래서 보통 서브클래스를 설계할때 기반클래스의 특징을 가지지만 더 확장하는 개념으로 많이 사용했었던거 같다. 앞으로 서브클래스 설계할때 LSP가 잘 지켜질지 의문이다. 리스코프 치환의 원칙은 ‘서브타입은 언제나 기반타입으로 대체할 수 있어야 한다’는 원칙이다.

[그림 1-11] 자바 컬렉션 API [그림 1-11]은 자바 컬렉션 API이다. 아래 진하게 표시된 것들은 클래스이며, 위쪽의<>라는 스테레오 타입으로 표시된 것들이 인터페이스이다. 이러한 컬렉션을 활용하는 소스가 다음과 같이 있다고 하자.

Utility.java class Utility { void add(Vector v) { v.add(); // // } }

이러한 유틸리티 클래스는 Vector 클래스만을 사용한다면 문제가 되지 않겠지만, 수행 속도를 높이기 위해 ArrayList나 LinkedList를 사용해야 한다면 다른 유틸리티 클래스가 필요해진다. 그래서, ArrayList나 LinkedList 형태를 사용하기 위해서는 다음과 같이 변경하는 것이 바람직하다.

Utility.java(개선된 소스) class Utility { void add(Collection collection) { collection.add(); // // } }

이렇게 개선된 유틸리티 클래스는 Vector와 ArrayList, 그리고 LinkedList 모두를 사용할 수 있는 구조로 변경되었다. 이것이 리스코프 치환의 원칙(LCP)을 활용한 것이 라고 할 수 있다 객체지향 설계 원칙 5-3 SRP (Single Responsibility Principle) 단일 책임의 원칙먼저 단일책임의 원칙을 한마디로 표현하자면 다음과 같다."하나의 객체는 하나의 책임만을 가진다" 이다. 여기서 책임이란 말의 의미는 변경해야할 이유라고 보면 되겠다. 그러니까 다시 풀어서 얘기 하자면 "하나의 객체는 오직 한가지의 이유로 인해서만 변경되어야 한다."정도가 되겠다. 평소에 소스를 보면서 복잡도, 결합도가 높다는 말을 많이 듣거나 사용했을것이다. 이게 바로 그말이다 ㅡㅡ그러면 이제 간단한 샘플을 보면서 단일 책임이 무엇인지 알아보겠다.내가 요즘 주식 재미에 푹~ 빠졌다. ㅎㅎ 그래서 주식관련한 샘플이 갑자기 생각났다. 다음의 클래스 구성도를 보자

[그림1] 샘플 클래슨 바로 주가 정보를 계산해서 알려주는 "주가정보" 클래스이다. 이 객체는 코스피 주가를 알고 싶은 객체와 코스닥 주가를 알고 싶은 객체가 사용하게 될것이다. 그러면 이 주가정보 객체에는 어떠한 문제점이 보이는가 ? 먼저 코스피정보만 취급하는 곳 에서는 코스닥 정보가 필요없다. 반대로 코스닥만 취급하는 곳 에서는 코스피 정보가 필요가 없다. 그러면 "현재코스피()", "현재코스닥()" 인터페이스중 하나는 불필요한 인터페이스가 될수 있다. 이런 문제는 크게 문제가 되어 보이지 않는다. 어차피 필요한 것만 가져다 쓰면 되기 때문이다. 하지만 많은 인터페이스가 존재한다면 복잡도가 증가될수는 있겠다.그러면 더 큰 문제는 무엇인가 ? 이 문제는 주가정보 객체가 업데이트 되어야 할때 발생한다. 만일 코스피 정보를 알려주는 내부로직이 아무런 변경이 없고 코스닥 정보를 알려주는 내부로직이 변경되었다면 코스피 정보만 사용하는 곳에서는 불필요하게 주가정보 객체가 업데이트 되는것이다. 왜 이런 문제들이 발생하는 것일까 ? 그것은 주가정보 객체가 두가지의 책임을 가지고 있기 때문이다. 위에서 책임은 무엇이라고 했는가 ? "책임이란 객체가 변경되어야 할 이유이다." 라고 했다. 그렇다 이 주가 정보 객체는 변경되어야 하는 이유가 두가지인 것이다.그러면 어떻게 이 문제를 해결할 것인가 ? 해결의 답은 간단한다. 두개의 책임을 하나씩 나누는 것이다. 주가 정보 객체를 코스피 정보를 계산해서 알려주는 객체와 코스닥 정보를 계산해서 알려주는 객체로 나누는 것이다. [그림2] 와 같다. [그림2] 이 밖에도 하나의 객체가 하나의 책임을 가지지 못하면서 발생하는 문제는 또 있다. 예들들어 하나의 책임을 여러개의 객체에서 같이 가지고 있다면 어떻게 될까 ? 바로 산탄총에 맞은 사람을 수술하는 의사가 될것이다. 일반 총에 맞으면 하나의 상처가 생긴다. 그러나 산탄총에 맞은 사람은 몸의 여러군데에 상처가 생긴다. 그래서 산탄총에 맞은 환자를 수술하려면 같은 한방을 맞더라도 여러군데를 시술해야 한다. 개인적으로 보면 5가지 원칙중 "단일 책임의 원칙" 이 제일 직관적이고 이해하기가 쉽다. 그것은 C 를 배울때 부터 이러한 얘기를 많이 들어와서 였던거 같다. 예들들어 처음 C 를 시작하면서 많이 듣는 얘기중 하나가 "하나의 함수에는 하나의 기능만을 넣어서 함수를 만들어라" 란 말을 많이 들어왔을 것이다. 그러나 사실 객체를 설계하면서 책임을 구분하고 나눈는일 자체가 쉽지 않다.ㅠㅠ 계속 반복하는 얘기지만 이런부분은 경험으로 채워가는 방법밖에 없다. 항상 생각하며 일하라. 단일 책임의 원칙이란 ‘클래스에는 한 가지 종류의 책임만을 두어야 한다’는 원칙이다. SRP:The Single Responsibility Principle 하나의 클래스에 여러 종류의 책임을 두지 말라는 것이다. [그림 1-5]의 클래스 다이어그램을 보자.

[그림1- 5] Shopping 클래스 [그림 1-5]를 보면, Shopping이라는 클래스 내부에 상품을 등록하기 위한 오퍼레이션 registerProduct()이 있으며, 회원으로 가입하기 위한 오퍼레이션 registerMember()도 있다. getProduct()는 상품정보를 조회하는 오퍼레이션이다. 이렇게, 하나의 클래스에 상품에 대한 오퍼레이션과 회원에 대한 오퍼레이션이 함께 있음을 알 수 있다. 말하자면 성격이 다른 오퍼레이션이 뒤섞여 있는 것이다 이러한 설계는 변경에 매우 취약한 구조가 되게 한다. 왜냐하면 상품과 관련된 클래스를 변경하거나, 회원과 관련된 클래스를 변경할 때 이 클래스를 변경해야 할 수도 있기 때문이다. 그리고 Shopping클래스를 변경하면 회원관리와 상품관리 클래스를 모두 변경해야만 한다. 그래서 [그림 1-5]을 ‘¼단일 책임의 원칙(SRP)’¸을 적용하여 다음과 같이 분리하여 설계한다.

[그림 1- 6] 분리된 Shopping클래스 이제, 회원이나 상품에 대한 변경이 있을 때, 함께 수정해야 하는 클래스가 줄어들게 되었다. 객체지향 설계 원칙 5-4 DIP (Dependency Inversion Principle) 의존 관계 역전 원칙먼저 의존 관계 역전 이란 어떤 의미인지 알아보자. A 객체가 B 객체를 멤버객체로 사용한다고 하면 A 객체는 B 객체를 사용하게 된다. B객체의 통제권이 A 객체에 있는것이다. B 객체는 A 객체의 존재도 알지 못한다. 이러한 관계에서 B 객체가 A 객체를 호출해야 하는 일이 필요할수 있다. B 객체가 A 객체를 Call 하는것을 의존관계 역전이라고 보면되겠다.채팅프로그램을 하나 만들려고 한다. 그러면 네트웍 처리하는 부분을 개발해야 할것이다. 그래서 나는 네트웍 관련처리를 맡아서 할 소켓 객체를 하나 만들어서 사용하려고 한다. 간단하게 보면 다음과 같다. [그림1] 이 구조에서 클라로직은 클라소켓 객체를 통해 서버와 통신을 한다. 클라소켁 객체의 Send 와 Receive 메소드를 비교해 보겠다.클라로직에서 어떤 데이타를 서버에 Send 하고 그에 맞는 응답을 Receive 해야 한다고 가정한다. 그러면 클라로직은 클라소켓의 Send 메소드를 호출하면된다. Send 후에 Receive 를 받아야 하는데 서버에서 언제 데이타가 올지 모른다. 그러면 어떻게 해야 하나 ? 제일 간단한 방법으로는 클라소켓 객체에게 Receive 가 왔는지 계속해서 물어볼수 있을것이다. 이런 방법을 사용한다면 아주 비효율적인 방법이 될것이다. 그렇다면 가장효과적인 방법은 무엇일까 ? 바로 클라소켓이 서버로 부터 데이타를 받았을때 클라로직에게 알려주는것이다.이 부분을 어떻게 구현할지 잠깐 살펴보도록 하자

[그림2] 클라이언트 쪽만 살펴보도록 한다. 먼저 클라로직과 클라소켓이 통신을 할수 있는 템플릿 클래스를 하나 만든다. 그리고 클라소켓에게는 AddEventObj 를 통해 자신의 객체 정보를 준다. 그러면 클라소켓은 Receive 가 왔을때 템플릿 클래스의 Receive 메소드만 호출하면 클라로직에 Receive 를 전달 할수 있다. 추상화를 많이 적용해보지 않았다면 이부분이 쉽게 이해가지 않을 것이다. 간단하게 샘플로 만들어 볼까 했는데 이놈의 귀차니즘이 ... (추후에 필요하다면 소스로 만들어서 추가 하겠다 ㅡㅡ)% 참고로 이 부분을 C 형식으로 간단히 구현하고 싶으면 Callback 함수를 등록해서 사용하는 방법도 있을수 있다. 간략하게 DIP 에 대한 간략한 소개의 샘플을 만들어 봤다. 이런 객체 설계에 익숙해 지려면 많은 시간 꾸준히 패턴을 적용한 설계를 해봐야 할것 같다. 그러나 패턴을 적용하기 위한 설계 또한 상당히 위험하다. 그렇다고 아무것도 안하고 계속 현실에 안주 하기 보다 실패를 하더라도 무엇인가 시도해 보고 노력해야 할것이다. 아무것도 하지 않는다면 실패도 없지만 성공도 없다. (오늘 점심시간 만화에서 나온대사 이다. 의존 관계 역전의 원칙은 ‘고차원 모듈은 저차원 모듈에 의존하면 안된다’라는 원칙이다. 말하자면, 의존 관계가 뒤바뀌면 안 된다는 것인데, 자주 변경되는 클래스에 의존하지 말고 추상 클래스나 인터페이스에 의존해야 한다는 뜻이다 일반적으로 추상 클래스와 인터페이스를 변경하기보다는 콘크리트 클래스(Concrete Class)를 변경해야 되는 경우가 더 많기 때문에, 콘크리트 클래스에 의존하면 그 클래스에 의존하는 클래스를 수정해야 하는 경우가 더 많이 있다 의존 관계 역전의 원칙(DIP원칙)은 자주 변경될 콘크리트 클래스나 변경될 가능성이 높은 ‘비즈니스 로직을 담은 클래스’에 의존하지 말고, 인터페이스나 추상 클래스에 의존할 것을 권고하는 원칙이다 객체지향 설계 원칙 5-5 ISP (Interface Segregation Principle) 인터페이스 격리 원칙객체지향의 설계원칙 중 마지막인 인터페이스 분리의 법칙이다.객체는 자신의 기능을 다른 객체가 사용하기 위한 대표적인 방법은 인터페이스를 노출하는 것이다. 객체가 노출한 인터페이스를 통해 객체간의 커뮤니케이션이 일어난다. 이 인터페이스 분리의 법칙은 인터페이스를 노출하는 방법에 관한 이야기이다. ISP 를 한마디로 표현하면 다음과 같다."클라이언트가 사용하지 않는 인터페이스 때문에 클라이언트가 영향을 받아서는 안된다." 여러개의 클라이언트가 사용하는 모든 인터페이스를 모아 두지 말고 하나의 클라이언트가 사용하는 하나의 인터페이스 집합을 만들어 사용해야 한다. 이것은 단일 책임의 원칙과 유사하게 해석될수도 있다. 하나가 인터페이스가 변경된다면 하나의 객체만 변경되어야 한다는 말이다.마침 이에관한 좋은 예제가 하나 있다. 내가 요즘 서버를 개발중에 있다. 그것도 두개의 서버를 동시에 개발한다. 하나의 게임에서 사용할 서버이고 편의상 A 서버 B 서버로 칭하겠다. 그런데 클라이언트 쪽에서는 이 서버에 통신하는 부분을 개발할 시간이 없단다. ㅡㅡ 그래서 이 A, B 서버와 통신하는 클라이언트 Stub 을 라이브러리 형태로 같이 개발해 달라고 한다. 귀찮게 시리 ㅡㅡ그래서 클라이언트 라이브러리를 개발하기 위해 다은과 같은 구성을 생각했다.

[그림 1] 위 그림을 보면 "A 클라이언트"는 A_prtocol 을 사용하여 "A 서버" 와 통신을 하고 B 클라이언트는 B_protocol 을 사용하여 통신할 것이다. 그러면 여기서 어떤 문제가 발생하겠는가 ? 먼저 "A 클라이언트"는 B_protocol() 을 사용하지 않는다. "A 클라이언트" 에서 알고 싶지도 알아야 할 필요도 없는 정보이다. 그런데 만일 B_protocol() 이 수정되었거나 또는 "B 클라이언트"의 새로운 기능때문에 인터페이스가 추가되어있다면 어떻게 될까 ? 네트웍 객체는 다시 컴파일 되어야 할것이고, 이것을 사용하는 클라이언트들도 다시 컴파일 되야 할 것이다. 그리고 계속 이런일이 발생하면 네트웍 객체는 필요 이상으로 점점 방대해 질 것이다. 이것이 위에서 언급한 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받는 것이다. 그렇다면 이와 같은 문제를 해결하기 위한 방법은 무엇이 있을까 ? [그림 2] 위와 같이 상속을 통해 공통부분을 관리하고 클라이언트에 종속적인 인터페이스는 따로 분리하여 객체로 관리하면 클라이언트가 다른 클라이언트와 독립적인 인터페이스를 가질수 있다. 이로서 객체지향 설계원칙 5가지에 대해 알아 보았다. 점점을 글을 쓸때마다 내용도 더 충실해 지고 내용전달도 잘 되것을 기대 하였지만, 현실은 그렇지 못했다. ㅡㅡ 이 놈의 귀차니즘 때문인지 시작한건 빨리 끝내야 겠다는 생각이 들어서 인지 서둘러 끝내는 느낌이다. 지금까지 살펴본 객체지향 설계 5 원칙은 어찌 보면 가장 쉽고 간단한 원리이지만 막상 적용하려고 하면 상당히 어렵고 복잡해 진다. 익숙해 질때 까지 이 원칙을 계속 적용해 봐야 할것 같다. 그렇지만 항상 불변의 원칙은 없는 것이니까 너무 집착할 필요는 없을것 같다. 인터페이스 분리의 원칙이란 ‘클라이언트는 자신이 사용하지 않는 메소드와 의존 관계를 갖지 않도록 해야 한다’는 원칙이다.

[그림 1- 9] 분리되지 않은 시스템 [그림 1-9]는 ISP를 적용하기 전의 모습이다. IManager인터페이스가 변경되면 관련된 A, B, 그리고 C 클래스를 모두 변경해야 한다. 왜냐하면 A, B 그리고 C 클래스에서 IManager를 참조하고 있기 때문이다. 이러한 시스템에 ISP를 적용하여 클라이언트에게 꼭 필요한 메소드만을 제공하도록 변경하면, IManager의 변경에 따른 변화를 최소화할 수 있다. [그림 1-10]은 이렇게 ISP를 적용하여 변경한 모습이다.

[그림 1-10] ISP적용하여 변경한 시스템

DPI(Deep Packet Inspection)=패킷의 출처, 경로, 형태를 파악하는 기술로 망 관리 관점에서 주요 통신사들이 도입을 서두르는 추세다. 분석 솔루션인 DPI를 기반으로 프리미엄 서비스, 서비스 제한, 과금 등 다양한 운영체계를 설계할 수 있다

□ 출제예상배경: 웹 애플리케이션 개발에서 현장에서 많이 사용되고 있는 데이터 포맷으로 출제 가능성이 있음 □ 대비사항: JSON의 정확한 개념과 키워드(name/value), XML과 비교, 장단점은 1교시형으로 준비가 필요함 □ 기본개념: JavaScript Object Notation, 자바스트립트를 객체형식으로 표현하는 것으로 인터넷에서 자료를 주고 받을 때 그 자료를 표현하는 방법으로, 문자열화 된 데이터를 객체화하는 경량의 데이터 교환 형식 □ 표기법: [형식] name/value 형식임 "firstName" : "홍" [object] 여러개 name/value는 {} 사용 {"firstName" : "길동", "lastName" : "홍"} [array] 배열은 [] 사용 { "employees" : [ {"firstName" : "길동", "lastName" : "홍"}, {"firstName" : "길서", "lastName" : "홍"}, {"firstName" : "길남", "lastName" : "홍"}, {"firstName" : "길북", "lastName" : "홍"} ] } □ 예제

Name: 홍길동
Age: 20
Address: 서울시 강남구 삼성동
Phone: 010-1234-5678

SDLC 전 단계가 Oriented Object개념 입각 방법론, 객체지향 방법론 가. 객체지향(Object Oriented) 방법론 정의
소프트웨어 시스템을 객체 모델을 기반으로 모델링하고 개발하는 방법론
실 세계의 개체(Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object)로 표현하는 개념
현실 세계의 사물 또는 개념을 객체라는 단위로 표현하는 방법으로 객체간에 메시지를 주고받는 형태로 시스템 구성
객체간의 메시지 통신을 통해 시스템을 구현하는 개발 방법 나. 객체 지향의 개발방법론의 특징
재 사용성, 유지 보수성, 이식성 통한 생산성 및 품질의 향상.
모형의 적합성 : 현실세계 및 인간의 사고 방식과 유사.
일관성, 추적성 : 전체 공정에서 각 단계간의 전환과 변경이 자연스럽고 신속함 다. 장점

구분 설명 요구사항 변경에 유연하게 대처 소프트웨어 시스템 개발 과정은 고객의 요구사항이 계속 변할 수밖에 없다는 특성을 가지고 있다. 그러므로 개발 과정에서 요구사항 변경을 유연하게 수용할 수 있어야 한다. 객체지향 개발 방법론이 이러한 유연성을 제공할 수 있다 기존 방식의 문제점을 극복 기존의 개발 방식에서는 데이터와 행위가 분리되어 개발이 복잡하고 통합하기 어려웠다. 객체지향 개발 방법은 데이터와 행위를 객체로 통합하기 때문에 이러한 문제점을 극복할 수 있다

객체지향 기법의 구성 요소 및 구조적 기법과의 비교 가. 객체지향의 기본 구성요소
Class간의 Relation, Object간의 상호작용은 메시지를 통해 이루어짐

구분 내용 클래스 (Class) - 같은 종류(또는 문제 해결을 위한)의 집단에 속하는 속성(attribute)과 행위(behavior)를 정의한 것 - 객체지향 프로그램의 기본적인 사용자 정의 데이터형 (User Define Data Type) - 클래스는 프로그래머가 아니지만 해결해야 할 문제가 속하는 영역에 종사하는 사람이라면 사용할 수 있고, 다른 클래스 또는 외부 요소와 독립적으로 디자인

객체 (Object) - 클래스의 인스턴스(실제로 메모리상에 할당된 것) - 자신 고유의 데이터(Attribute)를 가지며 클래스에서 정의한 행위(Behavior)를 수행. - 객체의 행위는 클래스에 정의된 행위에 대한 정의를 공유함으로써 메모리를 경제적으로 사용

메소드 (Method) - 클래스로부터 생성된 객체를 사용하는 방법. - 객체에 명령을 내리는 메시지라 할 수 있음. - 객체 간의 통신은 메시지를 통해 이루어 짐 인스턴스 (Instance) 프로그램에서 클래스를 통해 만든 실제의 실행 객체, 프로그램의 실행 단계에서 나타냄

나. 구조적 기법과 객체 지향 기법의 비교

객체 지향 기법에서의 구조적 기법과 대비하여 차별화 되는 개념 가. 기본원칙의 측면에서의 차별화

나. 객체지향 설계 원칙 측면에서의 차별화

종류 상세내용 개방폐쇄 원칙 OCP (Open Closed Principle) - 변화부분은 확장 가능하되, 변경은 어려운 구조(불변하는 부분만 클라이언트에 제공), Open(클래스 수직관계), Close(클래스 수평관계) - Strategy 패턴 : 인터페이스 변경은 어려우나 구현은 열려 있음

인터페이스 분리의 원칙 ISP (Interface Segregation Principle) - 객체 기능, I/F를 구체적으로 분리(입/출력 분할 사례 등) - 지나친 일반화를 경계해야 하며, ISP 어기면 비대한 클래스 발생

  <다수 기능 구현>          <기능분리 I/F를 통한 접근>

의존관계 역전 원칙 DIP (Dependency Inversion Principle) - 참조의 대상은 파생클래스가 아닌 추상클래스여야 함 - 객체의 참조는 부모 클래스의 인터페이스에 의존 리스코프 치환 원칙 LSP (Liskov Substitution Principle) - 자식타입들은 부모 타입들이 사용되는 곳에 대체될 수 있어야 함 - 자식클래스는 부모의 책임을 넘지 말고, 자식 기능의 제약 필요

단일책임 원칙 SRP (Single Responsibility Principle) - 객체는 둘 이상의 책임을 갖지 않는 형태를 가져야 함 - 두 개 이상의 책임을 가지면, 온전한 책임을 다할 수 있도록 분리

<다수 책임 수행>

<단일 책임 수행>

다. 객체 지향 방법론의 절차와 단계별 작업항목[OMT]

단계 작업항목 설명 객체지향 분석 객체 모델링-객체다이어그램 시스템 정적 구조 포착 추상화, 분류화, 일반화, 집단화 동적 모델링-상태다이어그램 시간 흐름에 따라 객체 사이의 변화 조사 상태, 사건, 동작 기능 모델링-자료흐름도 입력에 대한 처리 결과에 대한 확인 객체지향 설계 시스템 설계 시스템 구조 설계 성능 최적화 방안, 자원 분배 방안 객체 설계 구체적 자료 구조와 알고리즘 구현 객체지향 구현 객체지향언어(객체, 클래스) 프로그램 객체 지향 언어(C++,JAVA), 객체지향 DBMS

라. 객체 지향 방법론의 비교

객체 지향 기술의 향후 전망 및 실무 적용시 고려 되어야 될 사항 가. 적용 방법론 과 기술적 측면에서의 향후 전망

나. 객체 지향 기술 적용 시 고려 할 항목

PHP(Personal Home Page, Hypertext Preprocessor) 의 개요 가. 서버에서 동작되는 PHP 의 정의
하이퍼 텍스트 전 처리기로서 범용성을 지닌 서버에서 동작되는 스크립트 언어
동적(Dynamic)인 웹 페이지 설계, PHP로 작성된 Code 를 HTML 소스 문서에 이식 후 PHP 처리 기능이 있는 웹 서버에서 해당 코드를 인식하여 작성자가 원하는 웹 페이지를 생성할 수 있는 일종의 프로그래밍 언어. 나. PHP 의 등장 배경
정보의 수혜자만이 아닌 제공자 입장으로서 지식을 공유에 대한 욕구 발생.

다. Client 측 프로그래밍과 Server 측 프로그래밍의 비교

분류 설명 사용언어 서버 측 프로그래밍 - 프로그래밍 언어가 서버에서 실행 - 스크립트 해석기로 프로그램을 실행 - HTML 언어로 변환되어 Client 사용자에게 전달 - 클라이언트에는 서버 측 스크립트가 전송되지 않아 보안 유지 가능 - 데이터베이스 연동 가능 - 서버에 접속한 환경에서 프로그래밍이 가능 C Perl CGI PHP ASP(Active Server Page) JSP(Java Server Page ) 클라이언트 프로그래밍 - 프로그래밍 언어가 사용자의 웹 브라우저에서 실행 - 서버의 스크립트 해석 작업과 부하가 줄어 듬 - 모든 소스를 사용자가 확인할 수 있어 보안 유지 불가능 - 웹 브라우저만 있으면 어디서든 개발 가능 JavaScript VB Script Flash Active X

PHP의 동작 원리 및 특징. 가. PHP의 동작 원리 및 설명

나. PHP의 특징

항목 내용 성능 Zend Technologies 기술 적용 타 제품 대비 성능 우수 객체지향 PH5 에서 객체지향 기능 Full 지원 Easy 언어 C, Perl, Java 와 유사한 문법 체계(포인터, 구조체, 공용체 제거) OS, Server 지원 - 리눅스, 유닉스, 원도우, iOS 등의 운영체제에서 동작 가능 - Apache 와 IIS ( M/S Internet Information Server ) 등 거의 모든 웹 서버 지원 Operation - 외부 CGI 프로세서로 동작하는 방법 지원 - 하나의 서버 모듈로 탑재되어 PHP 스크립트 프로그램 처리 동작 지원 개발방법 통합 - 절차 지향 방식과 객체 지향 방식 동시에 지원 - 절차지향적 방식( Procedural Programming) 적용 가능: 함수단위의 모듈화 개발 가능 - 객체지향 방식(Object oriented Programming) 적용 가능: PH4 이상에서 지원 개발 방식 유연성 큰 응용 프로그램일 경우는 MVC(Model-View-Controller)와 같은 디자인 패턴사용가능 Database 통합 - 현재 업체에서 사용중인 거의 모든 DB 지원 - 엔터프라이즈급 대용량 DB 지원: Oracle, IBM DB2, MS-SQL - 중소 규모의 DB 지원 : PostgreSQL, MySQL, MSSQL XML 호환성 DOM과 SAX 표준을 따르는 각각의 파서를 제공 자유로운 개발환경 ASP 는 원도우 환경에서만 동작이 가능하나 PHP 는 거의 모든 OS 환경 지원 가능 OpenSource 사용자가 임의로 소스를 수정하여 사용 가능 다양한 lib지원 PDF, XML, 세션, 정규 표현식, SNMP, IMAP, COM 등에 대한 라이브러리 지원

유사 프로그램 비교 및 PHP 의 개선점 가. JSP, PHP, ASP 비교

나. PHP 의 개선점

버전 개선점 PHP 1.0 - 1994년 Perl Script 로 만듬 - 1995년 PHP(Personal Home Page) Tool 1.0 공개 PHP 2.0 1995년 HTML 형식의 데이터를 해석할 수 있는 별도의 패키지인 FI ( Forms InterPreter) 개발, PHP/FI 2.0 공개 PHP 3.0 - 기존 PHP version 많은 버그 발견 - PHP 내부 소스 코드 재 작성하여 PHP(PHP : Hypertext Preprocessor) 3.0 탄생 PHP 4.0 - PHP 스크립트의 Performance 향상시켜 새로운 프레임워크인 Zend 엔진 탄생 - 2002년 Zend 엔진 기반에서 수행되는 PHP 4.0 버전 출시 - 모듈화와 웹 서버 인터페이스 및 이식성 부분 개선 - 객체지향 언어인 Java 나 C# 처럼 클래스 이용 가능 PHP 5.0 1) Zend Engine 2.0 기반, PH4 문제점 보완. 2) 객체 지향 문법 전부 지원 3) XML 확장을 libxml2 XML Tool Kit 으로 재 작성하여 표준을 통합 지원 강화 : PHP4 XML(DOM, SAX, XLST) 확장 모듈이 서로 다른 라이브러리를 기반으로 생성되어 모듈간의 기능적 호환성 없음, DOM 파서를 통해 파싱한 출력문서를 SAX 파서의 입력문서로 사용 불가 4) SQLite 라는 파일 기반의 경량급 DB 지원 MySQL 4.1 버전의 새로운 기능을 지원하기 위해 기존의 MySQL 확장모듈 외에 MySQLi 이라는 이름의 새로운 확장 모듈을 제공, 5) Prepared Statement 와 트랜잭션 제어 추가 6) 멀티쓰레드 지원 ( 기존 CGI 방식에서는 Process 사용하면서 메모리 관리 비효율 )

7) New Memory Manager : Multi Thread 지원 – 메모리 절약 효과 8) 간편하고 쉽게 XML 데이터을 취급할수 있도록 SimpleXML 이라는 새로운 XML 처리기를 추가로 제공 PHP 5.3 1) Window 2000 이후 Version 만 지원 2) 실행 시간 속도가 증가, 메모리 사용량 줄임 ( Zend 엔진이 추가 개선됨) 3) 보안기능 강화 : crypt(), Hash(), md5() 기능 및 OpenSSL 확장 기능 개선 4) NameSpace 및 Garbage collection 기능 추가

다. PHP 의 주요 개선점의 요약

PHP 의 향후 발전 전망
OS에 기본 기능으로 탑재될 걸로 예상되며 Peer to Peer Network 환경에서 속도 향상 효과
인터넷 쇼핑몰, 블로그, 게임, 커뮤니티를 스스로 제작 가능함으로 활용가치가 높음
ASP,JSP 보다 성능 면에서 가장 우수하기 때문에 시장 지배력 강화 예상
Multicore CPU를 사용하는 Server system 에서의 성능 최적화를 위한 CPU Scheduling기법의 다양화 필요

공공부분 정보화 환경변화에 따른 정보시스템 감리의 개요 가. 최근 공공부분 정보화 환경변화

나. 정보화 환경변화에 따른 정보시스템 감리 필요성

최근 공공부분의 정보화 환경변화에 더불어 정보시스템 감리의 필요성 증대
성공적인 정보시스템 감리를 위한 감리 프레임워크 가. 정보화사업 감리 점검 프레임워크 V4.0(정보화진흥원,2012.12)
정보시스템 개발사업 뿐만 아니라 EAㆍISP수립, DB 구축, 운영ㆍ유지보수 등 모든 유형의 정보화사업에 공통적으로 적용 가) 사업 유형/ 감리 시점
EA, ISP, SD, DB, OP, MA 에 따라 사업 유형을 정의하고ㅗ, 감리시점은 생명 주기를 방연하ㅏ여 사업 유형에 따라 정의 나) 감리 영역
사업 영역/감리 시점에 따라 관점별로 구분 다) 감리 관점 점점 기준
감리가 대상 사업을 바라보는 관점
사업을 기반으로 대상 사업에 대한 방법론, 사업 추진 계획, 절차 등 사업에 대한 절차와 그 결과로 생성되는 산출물을 점검/ 평가화
감리 관점별 점검하는 기준으로, 각 관점의 특성, 또는 품질 기준으로 볼 수 있음 나. 정보시스템 감리 프레임워크 3.0 → 4.0 차이점
감리관점별 정보시스템 감리 절차 가. 감리수행 절차(이해 당사자별 역할 관점)
감리계약은 감리법인과 공공기관간에 체결하여야 하며 각 감리회차 별로 위 프로세스가 진행 나. 감리수행 절차(감리법인 관점)
공공정보화 환경변화에 성공하기 위한 정보시스템 감리 대응방안
기술적 측면 : 재공학 감리를 통한 시스템품질 향상
관리적 측면 : 상주감리/운영감리를 통한 사업관리 및 QA 지원

정보시스템 감리의 개념 가) 정보시스템 감리의 정의
감리 발주 기관 및 피감리인의 이해관계자로부터 독립된 자가 정보시스템의 효율성을 향상시키고 안전성을 확보하기 위하여 제 3자적 관점에서 정보시스템의 구축 및 운영에 관한 사항을 종합적으로 점검하고 문제점을 개선하도록 하는 것 나) 정보시스템감리 모델
감리를 수행하는 논리적인 흐름에 따라 구성 되어 있음
감리의 대상이 사업유형별로 감시 시점을 결정하고, 각 시점별로 감리 시행시 감리 영역을 구분하고, 감리 영역별 중점 점검 항목을 선정하여 감리 수행을 위한 모델로 사용
개념 모델은 정보시스템 감리 점검 프레임워크와 기본점검표, 감리영역별 지침으로 구분됨
정보시스템 감리의 활성화 방안
감리 기관의 난립으로 인한 감리 비용의 덤핑화를 방지하기 위해 감리비 하한가제도 도입
일정 수준 이상의 자격 요건을 갖춘 감리기관만이 감리에 참여 할 수 있도록 감리기관 자격요건 강화
감리 대상 사업 및 기과느이 확대로 시장활성화
전문적인 능력을 갖춘 인력만이 감리에 참여할 수 있도록 감리인 자격 부여

출처 : https://wikidocs.net/186

'Introduce > Certificate' 카테고리의 다른 글

10 Best Machine Learning Certification for 2020 (0)	2020.07.29
[Publication] CEWIT 2013 (0)	2017.03.02
정보처리기술사 (0)	2014.06.23
CPPG 시험대비 자료 (4)	2014.02.03

MISTERY

SW공학 - 기술사 준비 자료 수집

참조, 내부논리파일/외부연계파일의 복잡도 및 기능점수 가중치(지경부고시)

참조1, 외부입력의 복잡도 및 기능점수 가중치(지경부고시)

참조2, 외부출력/외부조회의 복잡도 및 기능점수 가중치(지경부고시)

- WBS는 프로젝트 전체 범위를 포함하고 있으므로 누락된 범위 존재 시 일정, 원가에 직접적인 리스크를 발생시키며, WBS를 투입물로 받는 모든 프로세스에 문제 발생

- Critical path 내의 작업이 지연되면, 프로젝트 전체 기간이 늘어나게 됨

include

include

은 protected로 선언되어 상속된 클래스에서만 제한적으로 사용

: protected

[그림 5-18] 조립 커넥터

- 간단한 순차적인 제어흐름을 표시하기에는 순서 다이어그램이 좋지만 반복이나 분기와 같이 여러 객체 사이에 일어나는 복잡한 상호작용은 커뮤니케이션 다이어그램으로 표시

[그림 5-24] 의존 관계

협 의

※ ISO15504(SPICE : Software Process Improvement Capability Determination) : 조직의 소프트웨어 개발 프로세스를 개선하고 개발자의 개발 능력을 향상시킴으로써 개발 위험을 통제

<분류 트리 기법 예제>

다이어그램 안에 있는 상품 구입, 상품 등록, 재고 확인, 구입 취소, 취소 확인 시나리오에 대하여 Actor(회원/관리자)와 시스템의 교환을 스토리로 기술한다.

5. 소프트웨어 생명주기별 품질보증 활동

[그림 1-10] ISP적용하여 변경한 시스템

'Introduce > Certificate' 카테고리의 다른 글

댓글

티스토리툴바

SW공학 - 기술사 준비 자료 수집

참조, 내부논리파일/외부연계파일의 복잡도 및 기능점수 가중치(지경부고시)

참조1, 외부입력의 복잡도 및 기능점수 가중치(지경부고시)

참조2, 외부출력/외부조회의 복잡도 및 기능점수 가중치(지경부고시)

- WBS는 프로젝트 전체 범위를 포함하고 있으므로 누락된 범위 존재 시 일정, 원가에 직접적인 리스크를 발생시키며, WBS를 투입물로 받는 모든 프로세스에 문제 발생

- Critical path 내의 작업이 지연되면, 프로젝트 전체 기간이 늘어나게 됨

include

include

은 protected로 선언되어 상속된 클래스에서만 제한적으로 사용

: protected

[그림 5-18] 조립 커넥터

- 간단한 순차적인 제어흐름을 표시하기에는 순서 다이어그램이 좋지만 반복이나 분기와 같이 여러 객체 사이에 일어나는 복잡한 상호작용은 커뮤니케이션 다이어그램으로 표시

[그림 5-24] 의존 관계

협 의

※ ISO15504(SPICE : Software Process Improvement Capability Determination) : 조직의 소프트웨어 개발 프로세스를 개선하고 개발자의 개발 능력을 향상시킴으로써 개발 위험을 통제

<분류 트리 기법 예제>

다이어그램 안에 있는 상품 구입, 상품 등록, 재고 확인, 구입 취소, 취소 확인 시나리오에 대하여 Actor(회원/관리자)와 시스템의 교환을 스토리로 기술한다.

5. 소프트웨어 생명주기별 품질보증 활동

[그림 1-10] ISP적용하여 변경한 시스템

'Introduce > Certificate' 카테고리의 다른 글

관련글

댓글

티스토리툴바