MISTERY

CEWIT 2013


Processing and Negotiation of Packet Traffic on Software Defined Network Controller


Reference :  http://www.stonybrook.edu/happenings/research/cewit-2013/



CEWIT_13_Proceedings.pdf


저작자 표시
신고

'Introduce > Certificate' 카테고리의 다른 글

[Publication] CEWIT 2013  (0) 2017.03.02
정보처리기술사  (0) 2014.06.23
SW공학 - 기술사 준비 자료 수집  (0) 2014.05.02
CPPG 시험대비 자료  (3) 2014.02.03

Comment +0

2개월은 기술사를 취득을 위한 장기 플랜 및 지금까지 경험사항 및 관련 기술의 기술사 시험의 입장에서 정의 및 정리.
6개월은 미 경험 분야에 대한 살아 있는 지식 쌓기 및 보안 자격증/네트워크 자격증/DB관련 취득
4개월은 SW 공학/수치 해석 등의 기초 과목의 기술사 시험 입장에서 정리
6개월은 수강 접수 및 본격 시험

왜 이것이 필요한가.
http://kin.naver.com/open100/detail.nhn?d1id=4&dirId=406&docId=752700

기출문제의 예 (제 80회 정보처리 기술사 문제 해설)
http://blog.ohmynews.com/ggomawitch/177381
제 81회 정보처리 기술사 문제 해설 
제 74회 정보처리 기술사 문제 해설 
제 75회 정보처리 기술사 문제 해설 
제 80회 정보처리 기술사 문제 해설 

기술사 수험 전략의 10계명

http://anyflow.net/
http://http.co.kr/
http://blog.naver.com/skim201c/120041029428

 

 

 

 

 

 

 

출처 : http://improf.egloos.com/2301698

 

 

 

 

 

 

 

 

 

 

신고

'Introduce > Certificate' 카테고리의 다른 글

[Publication] CEWIT 2013  (0) 2017.03.02
정보처리기술사  (0) 2014.06.23
SW공학 - 기술사 준비 자료 수집  (0) 2014.05.02
CPPG 시험대비 자료  (3) 2014.02.03

Comment +0

소프트웨어

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

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

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

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

  1. 소프트웨어 시스템 특성

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

소프트웨어 공학

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

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

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

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

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

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

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

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

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

  7. 소프트웨어 공학을 지원하는 기술의 유형 및 유형별 특징 가. 소프트웨어 공학 기술의 유형

유형 설명 사례 개발기술 요구공학 기술, 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 관리자의 관점을 지원함 프로젝트 전체적인 관리를 가능하게 함

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

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

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

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


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

구분 HW 신뢰성 SW 신뢰성 Lifecycle

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

  1. SW 신뢰성 연구 가. SW 신뢰성 Trade-off
  2. 신뢰성 목표가 너무 높게 설정되면 인도 시점이 미뤄지고, 개발 비용이 증가
  3. 신뢰성 목표가 너무 낮게 설정되면 사용자는 큰 불만을 가지고, 산업의 특성에 따라서 심각한 인명상의 피해 또는 재산상의 손해까지도 발생 나. 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 확보

  1. 분야별 SW 신뢰성 향상 방안

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


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

프로세스

  1. 개발 프로세스 : 프로젝트에서 이루어져야 할 중심 프로세스
  2. 수행해야 할 개발과 품질보증 작업
  3. code and fix 형
  4. 폭포수 모델(waterfall model)
  5. 프로토타입 모델(prototype model) : 사용자의 의견(feedback)이 중요한 모델
  6. 점증적 개발 모델(incremental model) : 반복적 모델, 점증적 모젤, 나선형 모델
  7. 나선형 모델(spiral model) : 위험관리를 중요시하는 모델
  8. V모델 : 테스트와 검증을 강조하는 모델
  9. 일정중심 설계 모델(design to schedule model) : 출시 일정을 정확히 맞추기 위한 모델
  10. 애자일 개발 프로세스
  11. 프로젝트 관리 프로세스 : 계획, 모니터링과 제어, 분석
  12. 비용, 품질, 기타 목표를 맞추기 위한 계획, 제어 작업
  13. 프로젝트를 수행하여 프로젝트의 목적을 달성에 초점
  14. 기간 : 프로젝트가 수행하는 동안
  15. 개발 프로세스와 프로젝트 관리 프로세스 관계

  16. 소프트웨어 형상관리 프로세스 : 변경을 관리하여 제품의 일관성을 유지 가. 정의

  17. 개발 중에 발생하는 변경을 자체적으로 컨트롤
  18. 시스템을 구성하는 아이템을 식별하고 정의하며 이들의 변경을 생명주기 동안 관리하고 아이템의 현재 상황과 변경 요청을 기록, 보고하며 아이템의 완벽성과 정확성을 검증하는 작업 나. 형상관리와 개발 프로세스 관계

  19. 제품 진화에 의한 변경

  20. 버그 수정에 의한 변경
  21. 요구 변경 다. 형상관리 기능
  22. 프로그램의 최신 버전 유지
  23. 지정된 버전으로 되돌아 갈 수 있는 기능
  24. 무허가 변경이나 삭제를 방지
  25. 현 시스템에 대한 모든 정보, 문서 등의 정보를 모아 보관 라. 형상관리 메커니즘
  26. 형상관리 대상 파악과 베이스라인 지정
  27. 버전 관리
  28. 접근제어
  29. 품질보증 프로세스 : 소프트웨어 프로젝트의 프로세스와 프로덕트에 대한 품질을 관리하고 향상시키는 것 가. 인스펙션 프로세스 : 개발 결과에서 결함을 찾거나 방지하기 위한 노력 나. 프로세스 관리 프로세스 : 소프트웨어 프로세스를 개선
  30. 프로세스를 개선하여 생성된 결과의 품질과 생산성을 향상에 초점
  31. 기간 : 프로젝트가 진행되는 기간을 초과한 긴 시간 동안

개발 프로세스

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 추구하는 방법론

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

  1. 하향식 접근 방법으로 추상화 모델링 하는 폭포수 모델 개념 가. 폭포수 모델(Waterfall Model)의 정의
  2. 계획, 요구사항분석, 설계, 구현(개발), 시험 및 유지보수 과정을 순차적으로 접근하는 방법
  3. 문서와 결과물에 중점
  4. 분석, 설계, 구현(개발), 시험 및 유지보수 과정을 순차적으로 접근하는 고전적 라이프사이클 패러다임(classic Life-Cycle Paradigm) 나. 폭포수 모델의 특징
  5. 표준화 되어 있는 양식과 문서 중심의 프로세스 및 프로젝트 관리 강조
  6. Phase Testing : 각 단계별 검증->다음 단계 진행
  7. 결과물(Frozen Deliverable) : Phase Testing을 거친 산출물들은 정식변경 절차에 의해서만 변경 가능
  8. 단계별 작업순서에 의해 체계적 순차적으로 진행(하향식, 명확한 요구사항 정의 필요)
  9. 폭포수 모델의 프로세스 및 장∙단점 가. 폭포수 모델의 프로세스

  10. 각 단계는 산출물의 완벽성을 요구한다. 하지만 폭포수는 사용자가 소프트웨어를 볼 수 있는 시점이 완료된 이후이므로 사용자 요구사항 분석이 어려운 문제점을 가지고 있다. 그러므로 신규 사업과 같은 프로젝트 보다는 이미 경험이 있고 위험 낮은 프로젝트 모델로 적당하다.

  11. 사용자 의견이 다르거나 중간 결과를 점검한 결과 전 단계의 작업에 결함이 있다면 다시 수정하도록 전 단계로 돌아가는 피드백이 존재
  12. 응용분야가 단순하거나 잘 알고 있는 경우에 적합
  13. 비전문가가 사용할 시스템을 개발하는데 적합

  14. 폭포수 모델의 프로세스 및 주요 산출물, 적합한 프로젝트 특성 나. 폭포수 모델의 장∙단점

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

  1. 폭포수 모형의 주요활동 및 산출물 가. 계획
  2. 문제정의
  3. 시스템의 성격을 파악하여 비용과 기간을 예측
  4. 개발 방법과 각 단계에 필요한 자원을 결정 나. 요구분석
  5. 기능, 성능, 사용 용이성, 이식성 등 목표 시스템의 품질을 파악
  6. 요구분석서(요구명세서) : 사용자와 개발자의 의사소통 수단으로 사용되므로 정확하고 간결하고 완벽하게 이해하기 쉽고 일관성을 유지하도록 작성 다. 설계
  7. 시스템 구조 설계 : 시스템을 이루는 모듈의 관계 구조
  8. 프로그램 설계 : 각 모듈 안에서의 처리 절차나 알고리즘을 설계
  9. 사용자 인터페이스 설계 : 사용자에게 보이는 부분을 설계
  10. 설계서(설계 명세서) : 소프트웨어 구조를 기술한 것으로 각 모듈의 기능과 모듈 사이의 관계 => 개략 설계서 : 모듈 관계를 고려하여 모듈의 구조를 기술 => 상세 설계서 : 모듈의 인터페이스를 정의 라. 구현
  11. 단위 테스팅(unit testing)
  12. 코드 검사(code inspection) : 코딩 스타일에 맞추어졌는지 눈으로 확인 마. 시험
  13. 통합 테스팅
  14. 시스템 테스팅
  15. 알파 테스트 : 내부에서 실제로 테스트
  16. 베타 테스트 : 선택된 사용자가 실제로 테스트 바. 인수
  17. 인수 테스팅(acceptance testing) : 설치 후 인수를 받는 사용자나 발주자가 시험

  18. 폭포수 모형(Waterfall, Classic, Phased Model)의 한계

  19. 설계와 코딩 및 테스트를 지연시킬 우려, 불필요한 문서작성 노력, 재사용의 기회 줄어듦
  20. 사용자의 요구에 대하여 정확한 의견 수렴 어려움, 프로그램 개발 상황의 반영 못함
  21. 폭포수 모델 적용 시 고려사항 1) 관리가 상대적으로 쉬우나, 요구사항의 변경에 대한 대응력이 떨어짐 2) 기술 위험이 낮고, 유사한 프로젝트 경험이 많은 경우 적용, 요구사항이 비교적 명확히 정의되어 있는 경우 적용

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

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

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

  1. 프로토타입 모델 프로세스

  2. Horizontal Prototyping(수평적 프로토타입)과 Vertical Prototyping(수직적 프로토타입) 가. Horizontal Prototyping(수평적 프로토타입)의 특징 1) 행동적 프로토타입(Behavioral Prototype) 또는 모형(Mock-up) 이라고도 함 2) 실제 제품이나 서비스가 나오기 전에 사용자 입장에서 만드는 프로토타입 3) 목적 : 명확한 요구사항 파악

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

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

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

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


  1. SW품질 향상을 위한 반복적 개발(iterative development) 모델 개요 가. 반복적 개발(iterative development) 모델 개념
  2. 사용자의 요구사항 일부분 혹은 제품의 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델(폭포수+프로토타입 모형, 각각의 Iteration은 mini-Waterfall 개념)
  3. 처음부터 시스템 전체의 기능을 대상으로 하되 릴리즈 할 때마다 기능을 더 완벽히 개발하는 형태 나. 특징
  4. 재사용, 객체지향, RAD 모형의 기반 역할
  5. 폭포수 모델, 프로토타입 모델, 나선형 모델의 집합
  6. 진화형(Evolution Model) 개발 모델 가. 진화형 모델의 정의
  7. 시스템이 가지는 여러 구성요소의 핵심 부분을 개발한 후, 각 구성요소를 개선/발전시켜 나가는 개발 모델 나. 진화형 개발 모델의 특징
  8. 다음 단계로의 진화를 위해 전체 진화 과정에 대한 개요가 필요
  9. 시스템의 요구사항을 사전에 정의하기 어려운 경우, 프로토타입을 만들고 이를 다시 분석하여 요구사항을 진화시켜 나가는 방법
  10. 프로토타입은 재사용을 전제로 함
  11. 증분 설계가 다음 설계에 반영됨 다. 진화형 모델의 프로세스

  12. 1단계 진화 : 시스템의 각 구성 항목의 핵심 부분을 포함하는 최소의 시스템 개발

  13. 2단계 이후 진화 : 이전 단계의 시스템을 개선하게 됨
  14. 예 : 워드프로세스를 개발할 때 릴리즈 1에 입력, 편집, 포매팅 기능이 기본적으로 가능하게 하고 릴리즈 2에서는 같은 기능이지만 성능을 향상한다든지 기능을 개선
  15. 점증적 개발 모델(Incremental Development Model) 가. 점증적 개발 모델의 개념
  16. 폭포수 모델의 변형이며 소프트웨어의 구조적 관점에서 하향식 계층구조의 수준별 증분을 개발하여 이들을 통합하는 방식
  17. 요구분석서에 나타낸 시스템을 기능별로 여러개의 서브시스템으로 나누고 기능만을 포함한 서브시스템을 릴리즈하고 다음에 새로운 기능을 추가해 나가는 형태 나. 점증적 개발 모델의 특징
  18. 폭포수모델의 변형 : 프로토타입 모형의 반복개념을 선형순차 모델 요소들에 결합
  19. 프로토타입과 같이 반복적이나 각 점증이 갖는 제품인도에 초점(요구사항 명확시 사용)
  20. 규모가 큰 개발 조직일 경우 자원을 각 증분 개발에 충분히 할당할 수 있어, 각 증분의 병행 개발을 통해 개발 기간을 단축시킬 수 있음.
  21. 과도한 증분 및 병행 개발일 경우 위험, 증분 개발 활동 간의 조율에 많은 노력 필요 다. 점증적 개발 모델의 프로세스

  22. 첫 번째 점증은 위험이 높고, 검증도 안 되고 경험이 없는 기술 아키텍처 전체를 대상으로 하도록 하며, 기술진이 마감일까지 제품을 완전하게 구현할 수 없을 때 유용함

  23. 예 : 워드프로세스를 개발할 때 릴리즈 1에 문서의 입력 기능을 완성하고 릴리즈 2에 편집기능을 추가하며 릴리즈 3에 다양한 글씨체와 서식을 사용할 수 있도록 포매팅 기능을 추가
  24. 점증형 개발모델과 진화형 개발모델의 비교

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


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

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

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

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

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

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

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

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

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

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

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


  1. V 모델 가. V 모델 정의
  2. 폭포수 모델에 시스템 검증과 테스트 작업을 강조 나. V 모델 프로세스

  3. V 모델 장/단점 및 적용 분야 가. V 모델 장/단점

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

  1. 일정중심 설계 모형의 개요 가. 일정중심 설계 모형의 정의
  2. 일정중심 설계 모형은 SW생명주기 모형중 정해진 일정에 SW를 출시하기 위한 모형
  3. 단계적으로 여러 차례의 반복적인 Cycle을 거치면서 일정에 맞추기 위하여 변형된 모델 나. 일정중심 모형의 특징
  4. 우선순위 기초 : 사용자 요구에 대해 우선순위를 정하여 이를 기초로 각 Cycle 계획
  5. 반복적 Cycle : 단계적 여러 차례 Cycle을 거침
  6. 일정 중심 : 일정을 맞추기 위한 출시 계획
  7. 일정중심 설계 모형의 개념도 및 장/단점 가. 일정중심 설계 모형의 개념도

  8. 사용자 요구사항에 기초하여 일정 중심의 설계 모형 나. 일정중심 설계 모형의 장/단점 1) 장점 : 초기 단계 중요한 기능들의 설계, 구현 후 상대적으로 덜 중요한 기능은 나중에 구현함으로써 일정 조절 가능 2) 단점 : 우선순위가 낮아 출시에 포함되지 않을 기능의 분석, 설계에 시간 낭비 발생 다. 반복적 개발 모형과의 차이점

  9. 단계적으로 여러 차례 반복적인 Cycle을 거친다는 점에서 유사
  10. 일정중심 모형은 최종 목표와 출시가 명확하지 않은 상태로 시작하고 정해진 일정에 맞추기 위해 중간에 중단할 수 있다는 점에서 차이점
  11. 일정중심 모형의 적용에 적합한 프로젝트 가. 소프트웨어 제품의 출시 날짜가 매우 중요한 경우에 적합한 모형 나. 목표 일정을 달성할 수 있을지 불확실 한 경우 위험을 면할 수 있음

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

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

  1. RAD 사이클

  2. 개발자와 고객 사이에 피드백 루프를 둬서 유연성을 증가시킴

  3. 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) 리뷰 실시 시 초점 - 검증하는 명세 부분에서 처음 성립한 사전 조건과 나중에 성립한 사후 조건이 변하지 않았는가 - 명세 부분의 논리적인 구조로부터 원시 코드로의 변환이 논리적인 추론에서 적당한가

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

계획

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

  13. 소프트웨어 프로젝트 계획에서 일정계획을 위한 작업순서

  14. 작업분해->작업 소요시간 및 우선순위 결정->CPM 네트워크 작성->CP(Critical Path) 추출->일정표 작성

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

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

  1. 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원 (문제의 단가조건으로 계산)

  1. WBS 고유 식별자 Code Of Accounts 가. Code Of Accounts의 정의
  2. WBS의 각 요소를 고유하게 식별하는데 사용되는 숫자 또는 알파벳으로 구성된 고유ID, 넘버링 체계
  3. WBS에서의 Code Of Accounts 구성 방법 및 예시 가. WBS Code Of Accounts 구성 방법 [1차 분류]
  4. 공통관리(WA), 영업/계약(WB), 착수(WC), 분석(WD), 설계(WE), 구현(WF), 적용(WG), 종료(WH) [2차 분류 - 나머지 분류]
  5. 기본 : 각 작업은 순서 별로 1단위씩 증가하여 적용(1, 2, 3, ..., 100, 101, ...)
  6. 추가 : 세부 분류 나누어 구성(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관리 프로젝트 수행 중에 하는 관리 진척관리를 통해 진척 상황에 따라 추가작업을 정의하거나 세분화하는 과정

  1. 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를 투입물로 받는 모든 프로세스에 문제 발생

  1. CPM(Critical Path Method) 네트워크 가. 정의
  2. 노드와 간선으로 구성된 네트워크
  3. 노드에는 작업을 표시하고 간선은 작업사이의 선후 의존관계를 나타냄
  4. 간선을 나타내는 화살표의 머리에 있는 작업은 화살표 꼬리에 있는 작업이 끝날 때까지는 시작할 수 없음
  5. 이정표 : 프로젝트의 중요한 중간 결과를 완성하였다는 표시 나. CPM의 장점
  6. 관리자의 일정 계획에 도움을 줌
  7. 프로젝트의 작업 사이의 관계 나타내며 최장경로를 파악이 가능
  8. 병행작업이 가능하도록 계획 및 자원 할당이 가능
  9. 다른 일정 계획안 시뮬레이션이 가능
  10. 프로젝트 일정을 점검하고 관리 가능
  11. 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 내의 작업이 지연되면, 프로젝트 전체 기간이 늘어나게 됨

  1. Critical Chain과 Critical Path의 개념적 비교 가. Critical Chain의정의
  2. 프로젝트 Resource 측면에서 단순 Activity의 선후행이 아닌 투입 자원들의 연관관계를 통해 구성된 Activity 경로 나. Critical Path의정의
  3. 프로젝트의 전체 일정을 지연 시키지 않고 가질 수 있는 여유기간이 0인 Activity들로 연결된 경로(인력 측면의 자원 제약요소 발생 가능성 내포)
  4. 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)형태의 도구로서, 각 업무별로 일정의 시작과 끝을 그래픽으로 표시 - 과업을 독립적인 활동으로 간주하고 상호 연결된 속성을 미고려 - 작업 순서 흐름을 파악 - 작업의 병행 진행을 표현 - 인적자원 및 기타 자원의 할당에 사용


  1. 개발 실무자 관점에서의 개발 일정 준수 향상 방안 가. 개발 위험 요소의 사전 제거 방안
  2. S/W 측면: 각 기능별 대응 가능 여부를 사전 선행 개발을 통해 개발 가능 여부를 파악함
  3. H/W 측면: 각 Component 별 성능과 기능 위주 검증을 선행 나. 신규 사양에 대한 NUDD 적용 방안 ( 특정 기업에서 사용하고 있는 예 )
  4. 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 확보

요구분석

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

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

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

  1. 페르소나를 하는 이유

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

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

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

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

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

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

관리원칙 고려사항 정확한 시스템 목표 식별 기대관리(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)

나. 요구사항 명세 속성

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


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

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

  1. 모형기반 정형명세 Z 정형명세 가. Z(제드) 정형명세의 특징
  2. 시스템의 자료구조와 상태 및 상태변환 연산을 구문적으로 구분하지 않고 스키마를 이용하여 동일하게 표현
  3. 명세의 기본작성 단위는 스키마 : 스키마 단위로 명세를 분할하여 작성하므로 시스템의 구조적 개발 지원
  4. 스키마는 상태변수를 소개하고, 그 상태에서 제약과 연산을 정의
  5. 명세는 정형명세와 함께 비정형 기술을 허용
  6. 각 스키마의 세분화가 가능하므로, 작성된 명세의 세분화가 가능, 세분화의 결과로 명세간의 일치성 검증용이 및 스키마의 재사용성 높음
  7. 명세의 도식적인 표현으로 시스템 개발 참여자가 작성된 명세 이해용이
  8. 스키마는 스키마 합성, 스키마 재명명, 스키마 은닉과 같은 연산을 사용하여 조작 가능
  9. 명세안의 상태와 연산의 구문적인 구별이 없어서, 각 스키마들간 존재하는 관계를 파악하기 위하여 전 명세를 검토해야 하며, 고급언어로의 변환과정이 복잡 나. Z 정형명세의 스키마의 구조

  10. 스키마 시그니쳐 : 시스템의 상태를 구성하는 개체를 정의

  11. 스키마 술어 : 그러한 개체에 대해 언제나 참인 조건을 지정(불변 조건 : invariant)
  12. 스키마가 연산을 정의할 때 술어는 사전조건(pre condition), 사후조건(post condition)을 지정
  13. 이러한 조건들은 연산전후의 상태를 정의
  14. 사전조건과 사후조건의 차이는 연산 스키마에서 지정된 행동을 정의
  15. 정형명세 기법의 특징과 제약사항
  16. 엄격하고 상세한 분석을 통해 프로그램의 오류를 줄여 SW의 품질을 향상
  17. SW의 신속한 인도 및 적시성이 요구되는 SW에는 부적합
  18. 또한 정형기법은 사용자 인터페이스와 사용자 상호작용을 지정하는데는 적합하지 않음
  19. 정형 기법은 확장성이(시스템의 크기가 증가함에 따라 정형명세를 개발하기 위해 필요한 노력과 시간이 급격하게 증가) 떨어져서 비교적 규모가 작은 중요한 커널시스템 개발 프로젝트에 활용

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

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

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

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

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


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

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

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

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

나. 질문 전개 방법

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

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

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

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

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


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

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

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

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

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

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

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

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

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

요구분석방법

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

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

  2. 자료 흐름도 작성 예 가. 자료 흐름도 예

나. 식빵 공장 자료 흐름도

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

  1. 자료 흐름의 균형
  2. 상위 단계의 어떤 프로세스에 대한 입력과 출력 자료 흐름은 분할된 하위 단계의 자료 흐름도에 입출력이 되어야 함

  3. F라는 자료 흐름이 B와 C로 구성되어 있으면 자료의 균형 원칙에 위배되지 않음 그러므로 F라는 흐름이 B와 C로 구성된다는 사실이 명시되어야 함


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

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

  1. 자료사전 사용 예

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

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

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

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


  1. 사용 사례 다이어그램(use case diagram)
  2. 시스템의 기능을 나타내기 위하여 사용자의 요구를 추출하고 분석하는데 사용
  3. 외부에서 보는 시스템의 동작에 초점
  4. 사용 사례(use case)와 액터(actor)로 구성
  5. 액터 : 시스템 범위 밖에 존재, 시스템과 상호 작용하는 외부 엔티티
  6. 사용 사례 : 시스템 안에 존재, 외부 동작(external behavior)

  7. 사용 사례 작업 순서 가. 액터 찾기

  8. 시스템과 작용하는 외부 엔티티
  9. 액터는 사람이 될 수도 있고 외부 시스템이 될 수도 있음 나. 사용 사례 찾기
  10. 소프트웨어를 사용할 업무나 조직의 프로세스를 기술하는데 사용
  11. 시스템의 어떤기능을 수행할 때 정상적인 흐름만이 아니라 오류, 예외 케이스도 포함 다. 사용 사례 관계 찾기
  12. 포함관계(include) : 사용 사례 중복을 줄임

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

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

설계 원리와 아키텍처

  1. 소프트웨어 설계
  2. 소프트웨어를 이루는 모듈들을 정의하고 모듈 사이의 인터페이스를 기술하는 것을 의미
  3. 산출물 : 시스템 구조도와 모듈의 상세한 알고리즘, 자료에 대한 설계가 포함된 설계서
  4. 시스템 구조도 : 소프트웨어를 구성하는 모듈을 정의하고 모듈 사이의 관계를 나타내는 문서

  5. 아키텍처 설계 : 전체 시스템을 이루는 서브시스템, 또는 모듈이 무엇이며 서브시스템 사이의 관계를 파악하는 작업

  6. 인터페이스 설계 : 서브시스템 사이의 인터페이스를 설계하고 정의하는 작업
  7. 모듈 설계 : 시스템의 컴포넌트 되는 모듈, 즉 프로그램의 알고리즘에 대한 설계 작업
  8. 자료저장소 설계 : 파일이나 데이터베이스를 설계하는 작업
  9. 사용자 인터페이스 설계 : 메뉴나 입력 양식, 출력 화면 및 인쇄물을 설계하는 작업
  10. 설계의 원리 및 소프트웨어 설계의 원리 가. 설계의 원리

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

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

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

  1. 추상화

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

가. 개념도

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


  1. 모듈화
  2. 모듈을 별도로 컴파일할 수 있어 모듈을 수정해도 전체 시스템을 다시 컴파일 할 필요가 없음
  3. 디버깅에도 도움이 되어 시스템의 문제를 국한시키며 시스템을 고치는 작업이 수월
  4. 결합도 및 응집도 가. 결합도
  5. 모듈간의 상호 의존하는 정도를 의미
  6. 모듈 사이의 의존하는 정도

  7. 자료 결합(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) : 아무 관련 없는 처리 요소들로 모듈이 형성되는 경우
  • 응집력을 판단하는 기준

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


  1. 소프트웨어 아키텍처 가. 정의
  2. 외부에서 인식할 수 있는 특성을 가진 소프트웨어 구성요소들의 구조 나. 관점(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) 위 응용에 대한 모듈 뷰(논리 뷰)작성을 위한 컴포넌트를 제시하고 아키텍처를 작성하시오

  1. 아키텍처 스타일의 의미와 유형 가. 아키텍처 스타일의 의미
  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를 계층이라는 단위로 분할하여, 각 계층은 오직 이웃한 계층끼리만 통신 - 시스템의 수정성과 이식성 품질특성 제공

  1. 주어진 문제 분석과 C&C 뷰 기반 아키텍쳐 스타일 제시 가. 주어진 문제 분석

  2. 문자열을 받아서 대소문자 변환 후 출력하는 애플리케이션

  3. 필요 구성 요소 : 입력 모듈, 변환 모듈, 출력 모듈 나. 아키텍처 스타일 선정

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

  • 컴포넌트(Component)은 데이터 흐름상 데이터에 영향을 주는 기능을 기준으로 추출함
  • 커넥터(Connector)은 컴포넌트와 컴포넌트 사이의 의미관계를 기준으로 추출함
  • Pipe & Filter 아키텍처 스타일에 따른 아키텍처 작성

  • Filter : 위에서 도출한 입력, 분리, 대문자화, 소문자화, 결합, 출력 컴포넌트를 필터로 표현

  • Pipe : 위에서 도출된 커넥터가 파이프에 해당함
  • 위에서 도출한 Filter(컴포넌트)와 Pipe(커넥터)를 도식화 하여 아키텍처를 작성함
  • 모듈 뷰(논리 뷰)작성을 위한 컴포넌트 제시 및 아키텍처 작성 가. 모듈 뷰(논리 부) 작성을 위한 컴포넌트 제시

  • 분리, 소문자화, 대문자화, 결합 컴포넌트는 C&C 뷰와 1:1로 매핑됨

  • 모듈 뷰에서는 실제 시스템이 동작을 하는데 필요한 컴포넌트인 주 모듈, 구성 등이 추가됨
  • C&C View에서 표현된 입력과 출력은 모듈 뷰에서 Stdio 라이브러로 대체됨.


  1. 아키텍쳐의 재활용과 품질속성을 달성하기 위한 아키텍처 스타일 가. 아키텍처 스타일
  2. 아키텍처를 구성하고 있는 컴포넌트 유형과 실행시간에 이루어지는 그들간의 제어, 데이터 전송 패턴 나. 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 배치/설치


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

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

  1. IEEE1471의 개념적 모델 및 구성요소 가. IEEE 1471의 개념적 모델

  2. 아키텍처 개발에 관련된 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 선택되어 설계된 아키텍처에 대한 논리적 근거

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

객체지향 설계

  1. 객체지향 설계 가. 모델
  2. 기능적 모델 : 사용자에게 보이는 외부 기능
  3. 정적 모델 : 객체 모델이라고도 하는데 시스템을 구성하는 요소들, 즉 객체의 관계를 표현 => 정적 : 시간적인 요소가 개입되지 않은 즉 변하지 않는 구조적인 관계를 의미
  4. 동적 모델 : 시간적인 요소가 고려된것을 동적 모델, 시간이 흐름에 따른 객체의 상태 변화라든지 메시지 호출 순서 등을 나타냄

  5. 사용 사례 다이어그램 : 요구를 파악하기 위하여 시스템의 기능적인 측면을 모델링

  6. 순서 다이어그램 : 시스템 내부 관점에서 객체들의 상호작용을 나타낸 것으로 사용 사례 단위로 그리게 되므로 기능적 모델과 밀접한 관련을 맺고 있음 나. 객체지향 단계와 다이어그램

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

정적 모델 객체 ◯ ◯

클래스 ◯ ◯ ◯ 컴포넌트

◯ ◯ 배치

◯ 동적 모델 인터랙션 ◯ ◯

액티비티 ◯ ◯

상태 ◯ ◯

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

나. 객체와 클래스 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로 구성되고 있음을 의미 라. 객체지향 개념도


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

  6. 위임의 구현 사례 및 상속과의 비교 가. 위임의 구현 사례

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를 사용 단일 상속만 가능 중복 구현 가능 작업의 레벨 분할을 위해서 사용 공동 작업을 위한 상호간의 인터페이스를 위해 사용


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

나. 결과 값


  1. 캡슐화(Encapsulation)와 정보은닉 가. 캡슐화 정의
  2. 서로 관련성이 많은 데이터들과 이와 연관된 함수들을 묶어서 처리하는 개념 나. 캡슐화 목적
  3. 내부 데이터의 보호 : 외부에서의 직접적인 데이터 접근 및 조작 미허용
  4. 모듈 독립성 향상 : 데이터와 함수의 결합 다. 캡슐화 기본원리

  5. 정보은닉은 외부객체에 내부 로직 및 구조, 데이터를 숨기는 것(메서드만 허용)

  6. 캡슐화는 정보은닉을 확장하여 내부 데이터 및 메서드를 묶어 처리하는 개념 라. 캡슐화 특징
  7. 변경이 발생할 때 부작용의 전파를 감소시킴
  8. 컴포넌트 재사용을 용이하게 해준다.
  9. 인터페이스는 단순해지고 시스템 결합도는 낮아짐 마. 캡슐화 장/단점

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

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

  1. 정보은닉 간단한 예제

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()함수를 찾기위해 애를 써야 할 것이다.


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

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

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

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

마. 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)

  1. 정적 모델(static model)과 동적 모델(dynamic model) 가. 정적 모델
  2. 클래스 다이어그램 : 클래스의 관계를 나타나는 다이어그램
  3. 객체 다이어그램 : 객체의 정적인 구조를 나타내는 다이어그램
  4. 컴포지트 다이어그램 : 컴포넌트의 합성구조와 커넥션을 나타내는 다이어그램
  5. 컴포넌트 다이어그램 : 코드 구조를 나타내는 다이어그램
  6. 패키지 다이어그램 : 패키지로 선언한 모듈의 구조를 나타내는 다이어그램
  7. 배치 다이어그램 : 소프트웨어의 하드웨어 배치를 나타내는 다이어그램 나. 동적 모델
  8. 인터랙션 다이어그램 : 객체들 사이의 메시지 교환을 나타내는 다이어그램
  9. 상태 다이어그램 : 하나의 객체가 가질 수 있는 상태와 상태의 변화에 의하여 동작을 나타내는 다이어그램
  10. 인터랙션 다이어그램 : 순서 다이어그램, 커뮤니케이션 다이어그램, 인터랙션 오버뷰 다이어그램, 타이밍 다이어그램
  11. 순서 다이어그램 : 객체의 메시지 호출을 울타리 형태로 표현
  12. 커뮤니케이션 다이어그램 : 객체의 메시지 호출을 네트워크 형태로 표현
  13. 인터랙션 오버뷰 다이어그램 : 순서 다이어그램과 액티비티 다이어그램을 합성하여 그리는 형태로 표현
  14. 타이밍 다이어그램 : 시간의 흐름에 따른 구성요소의 상호작용과 상태변화를 그리는 형태로 표현
  15. 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만을 포함 관계는 너무 많이 표현하지 않고 반드시 필요한 것만을 표현

  1. 정적 모델링의 대표적인 표현 클래스 다이어그램
  2. 객체, 클래스, 속성, 오퍼레이션 및 연관관계를 이용하여 시스템을 나타냄
  3. 시스템의 구조를 나타냄
  4. 클래스 : 객체들의 공통 구조와 동작들을 추상화시킨 것
  5. 객체 : 시스템이 수행되는 동안 생성되고 변경되며 소멸될 클래스의 인스턴스
  6. 소프트웨어 엔지니어는 분석 단계에 응용 도메인의 지식을 정리하기 위하여 클래스 다이어그램을 작성
  7. 자세한 인터페이스나 네트워크 통신, 데이터베이스 저장 등은 표시하지 않음
  8. 시스템의 가장 기본적인 구성요소와 구조적 관계를 발견
  9. 클래스, 속성, 오퍼레이션 표현
  10. 박스를 세 개의 부분으로 나누고 맨위에는 클래스의 이름, 중간에는 클래스의 속성, 맨 아래 부분은 오퍼레이션
  11. 속성과 오퍼레이션의 이름 앞에 표시한 +, -, # 기호는 클래스의 외부 투명성(visibility)을 나타내기 위한 심볼
  12. +는 public으로 선언되어 외부에서 접근 가능한 요소
  13. -는 private로 선언되어 외부에서 사용이 불가능
  14. 은 protected로 선언되어 상속된 클래스에서만 제한적으로 사용

  15. 인스턴스가 없는 추상 클래스나 구현이 없는 추상 오퍼레이션은 {abstract}라고 표시

  16. 클래스의 유형을 의미하는 스테레오 타입 표시도 가능

  17. 클래스 사이의 관계 표현 가. 관계 종류

  18. 연관 관계 : 클래스의 인스턴스가 다른 클래스의 인스턴스로 메시지를 전달하는 관계
  19. 집합 관계 : 전체 개념의 클래스가 부분 개념의 클래스를 포함하고 있는 관계
  20. 복합 관계 : 전체 개념의 클래스가 부분 개념의 클래스를 포함하고 있는 관계(부모없이 자식은 존재할 수 없음)
  21. 의존관계 : 두 사물간의 의미적인 관계로써 한쪽(독립) 사물의 변화가 다른(종속) 사물에 영향을 주는 관계
  22. 상속 관계 : 일반적인 클래스의 정의를 구체화 된 클래스가 상속받아 사용하는 개념 나. 연관 관계(Association)
  23. 연관 관계를 표시한 선의 끝에는 역할(role)을 표시
  24. Inventory와 video 클래스 사이의 연관 관계에 표시된 has와 exit가 역할
  25. 역할을 표시하는 이유는 연관 관계가 어떤 클래스로부터 연유된 것인지 나타내기 위함
  26. 역할의 표시로 관계의 목적을 더 분명히 할 수 있음
  27. 연관 관계의 끝에는 숫자가 표시되어 있는 경우 클래스의 인스턴스에서 연관된 링크의 개수를 의미
  28. 역할 위에 쓴 숫자가 다중도(multiplicity)
    • 은 다중도를 표시한 것이며 다수라는 것을 의미
  29. 양방향

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 : 동일 패키지 및 하위 클래스 접근가능

마. 코드 변환 예


  1. 클래스의 의존관계(Dependency Relationship) 구현방법 가. 클래스간의 의존관계 표현방식
  2. 클래스가 변경되었을 때 이것을 사용하고 있는 다른 클래스에 미치는 영향으로 아래의 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 선언 }

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

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

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

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

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

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


  1. 패키지 다이어그램
  2. 클래스를 의미 있는 관련된 그룹으로 구성하는 메커니즘
  3. 클래스를 논리적으로 그룹핑하는 것으로 java 프로그래밍 언어의 Package 선언으로 매핑
  4. 최상위층에는 구조적인 개체들(사용자 인터페이스, 비즈니스 도메인, 서브 시스템과 관련된 패키지)
  5. 하위층에는 더 작은 개념의 비즈니스 작업
  6. 소프트웨어 구조를 표현하는데 적합
  7. 패키지가 클래스의 그룹 이름으로 높은 수준의 추상화된 서브시스템을 표현
  8. 표현 방법
  9. 두 서브시스템 사이의 의존관계 나타냄
  10. myGUI가 java.awt에 포함된 내용을 사용하고 있다는 의미

  11. 패키지 다이어그램은 중첩이 가능

  12. Clerk User Interface 패키지 안에 Business System Client 패키지, Customer 클래스, Rental UI 클래스가 정의 되어 하나의 서브시스템으로 구성

  13. 패키지 다이어그램 표기법과 사례 가. 패키지 다이어그램 표기법

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

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

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

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

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

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

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

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

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

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

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

  1. 컴포넌트 다이어그램
  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] 조립 커넥터

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

다이어그램 설명 순서 다이어그램 시스템의 동작을 정형화하고 객체들의 메시지 교환을 울타리 형태로 시각화하여 나타냄 사용 사례 다이어그램에 관련된 객체를 추가로 찾아내는데 유용함 이를 참여 객체(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) 클래스 다이어그램에 표기된 클래스명과 매핑 가능하도록 객체 이름을 표기


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

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

  • 조건은 화살표 위에 괄호 안에 기술 I. 스테이트(State Diagram) 다이어그램의 개요 가. 스테이트 다이어그램의 정의
  • 클래스의 객체가 가질 수 있는 모든 가능한 상태를 보여주며, 특정 객체에 대하여 사전 발생에 따른 상태 천이과정을 묘사한 다이어그램
  • 객체가 보유하는 상태와 상태가 전이하는 제어흐름을 표현
  • 객체, 컴포넌트 또는 시스템을 대상으로 동적 행위를 상태(state)와 전이(transition)로 표현 나. 스테이트 다이어그램의 특징 1) 진입 조건, 탈출 조건, 상태 전이에 필요한 사건 등 자세한 사항이 기술 2) 설계 단계에서 클래스 객체의 동적인 행동 방식을 표현하는 데 사용 II. 스테이트 다이어그램의 예시

  • 문서 작성 및 결재 업무에서 문서의 상태 및 천이 과정을 묘사한 스테이트 다이어그램 Ⅲ. 상태 다이어그램 작성 방법 순서 가. 상태 다이어그램으로 작성하고자 하는 범위를 파악 나. 표현하려는 대상의 시작, 종료 상태를 파악 다. 객체가 어떤 상태들을 갖는지 찾아냄 라. 상태 변환과 관련된 이벤트, 액션, 조건을 찾음 마. 상태 머신이 올바로 작성되었는지 검증


  1. 액티비티 다이어그램
  2. 시스템의 동적인 부분을 모델링 하는 목적으로 사용되며 액티비티 사이의 제어 흐름을 보여주는 일종의 흐름도
  3. 상호 작용을 보여주는 또 다른 방법으로 액션이 어떻게 이루어지며 무엇을 수행하고 언제 발생하며 어떤 액션과 동기화 또는 병렬 수행되는지를 나타냄
  4. 시스템을 액티비티로 표현
  5. 액티비티 : 오퍼레이션의 집합이 수행됨을 나타내는 상태 Ⅰ. 비즈니스 작업흐름을 표현하는 활동 다이어그램(Activity diagram)의 개요 가. Activity 다이어그램의 정의
  6. 객체의 상태가 아닌 처리 로직이나 조건에 따른 처리흐름을 순서에 따라 정의한 다이어그램
  7. 어떠한 행위에 따라 객체의 상태를 표기
  8. 시스템 내부에 존재하는 여러가지 행위들 그리고 각 행위의 분기, 분기되는 조건 나. 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 다이어그램의 효과 가. 사건 발생에 관련된 객체들의 상화관계를 일렬로 도식화 나. 순서적 흐름, 병행 프로세스를 지원으로 불필요한 순서를 없애기 위한 효과가 있음


  1. 디플로이먼트 다이어그램(Deployment Diagram)
  2. 전체 시스템을 구성하는 하드웨어와 하드웨어의 연결 관계를 표현하는 다이어그램
  3. 각 하드웨어와 하드웨어에 배치되는 아티팩트(시스템에 존재하는 소스 코드, 산출물과 같이 물리적으로 존재하는 정보)를 표현
  4. 시스템의 물리적인 부분의 구성을 나타냄.
  5. 디플로이먼트 다이어그램은 실제 하드웨어적인 배치와 연결상태.
  6. 컴포넌트 다이어그램은 소프트웨어의 물리적 단위(Exe, DLL 등 기타 library)의 구성과 연결상태를 표현

  7. 육면체로 표현된 기호는 하드웨어를 의미하며, 사각형 기호는 아티팩트

  8. 디플로이먼트 다이어그램 구서요소 가. 노드(node) 『UML User’s Guide 』에는 ‘J노드란 실행 시간에 존재하고 컴퓨터 자원(Computing Resource)을 나타내는 물리적인 요소이다. 일반적으로 노드는 컴포넌트가 배치되는 컴퓨터나 장치를 의미한다”J라고 정의되어 있다. 노드는 물리적인 요소이며, 시스템이 실행될 때 존재하며 어느 정도의 메모리와 처리 능력을 갖춘 전산 자원이다

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

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

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

[그림 5-24] 의존 관계

  1. Timing Diagram 가. 교류 다이어그램의 또 다른 형태로 단일 객체 뿐 아니라 여러 개의 객체들에 대한 타이밍 제약 조건에 초점
  2. 여러 대상간의 상호작용을 시간에 따른 상태 변화의 형태로서 표현 나. 타이밍 다이어그램 표현법 – 가로선의 변화로 타이밍 변화를 나타내는 법 – 서로 선을 교차하는 방법으로 영역을 명시하여 타이밍 변화를 나타내는 법

  3. Interaction Overview Diagram 가. 액티비티 다이어그램과 시퀀스 다이어그램을 접목한 다이어그램 나. 액티비티들이 작은 시퀀스로 분리되어 표현

  4. Communication Diagram 가. 객체와 객체 사이에 메시지 호출 관계를 설계하는 다이어그램 나. 구성요소 – 객체간의 연결 관계를 강조 – Object – Link


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

클래스 재사용

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

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

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

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


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

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

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

환경 분류 내용 실행환경 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별로 검토 필요

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

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

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

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

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

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

나. 기대효과

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


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

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

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


객체의 테이블 매핑

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

SW 분리‧분할 발주

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

나. 분할발주 기대효과

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

※ 분할발주 프레임워크

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

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

※ 분할발주 단계

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

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

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

오픈소스

  1. 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하에 배포된 파일 자체를 수정한 경우에만 소스코드 배포 마. 오픈소스 소프트웨어의 개념
  2. SW의 설계도에 해당하는 소스코드를 공개한 상태로 실행 프로그램을 제공하는 SW로, 누구나 자유롭게 소스코드를 사용, 개작, 재배포할 수 있도록 허용
  3. 소스코드를 공개해 기술을 공유하도록 하는 것은 누구나 자유롭게 SW의 개발ㆍ개량에 참여하게 하는 것이 우수한 SW를 만드는데 도움이 된다는 생각에 바탕
  4. 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의 중간 범위

  1. 오픈소스 라이센스 비교

구분 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 라이센스 위반


  1. 공개SW 거버넌스 영역

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

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

  10. 오픈소스 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 등의 글로벌 상용 소프트웨어 제품의 종속 문제 해결 기술혁신 개발, 공개, 지속적 보완 과정을 통해 성숙한 소프트웨어 개발 환경 조성 수정 및 재배포 가능한 라이센스로 뛰어난 소프트웨어 출시


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

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

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

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

  1. 공급형태
  2. 공급형태를 기준으로 하면 패키지 라이센스, 볼룸 라이센스, 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시간 이내

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

O

협 의

연 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 등) 상태 확인 및 분석 지원 도구 테스트 통제 형상관리 테스트 수행에 필요한 다양한 도구 및 데이터 관리 테스트 관리 전반적인 테스트 계획 및 활동에 대한 관리 결함 추적/관리 테스트에서 발생한 결함 관리 및 협업 지원


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

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

ISO

  1. 소프트웨어 품질보증의 제품평가 분야의 국제표준 ISO 9126의 개요 가. ISO 9126의 정의
  2. 제품평가 분야에 대한 표준으로 소프트웨어 제품에 요구되는 품질을 정량적으로 기술하거나 소프트웨어 품질을 측정하는 척도
  3. 소프트웨어 품질의 특성을 정의하고 품질 평가의 Metrics를 정의한 국제표준으로 사용자 관점에서 본 소프트웨어의 품질 특성에 대한 표준
  4. 소프트웨어 품질의 특성을 정의하고 품질 평가의 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 기반의 기능성 측정방안 가. 기능성의 적합성(업무형태) 측정 - 제품설명서와 사용자문서에 업무에 이용하는 서식작성에 관한 기능 정보를 제공하고 있고, 제품설명서와 사용자문서에 기술되어있는 서식작성기능이 제대로 구현되어 있는지를 평가

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

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

  1. 공공사업에서의 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 결과에 대한 평가 수행


  1. 소프트웨어 테스팅 국제 표준, ISO29119의 개요 가. ISO29119의 정의
  2. SW 개발 수명주기 전 과정에 걸쳐있는 테스팅 프로세스와 관련 산출물 표준 나. ISO29119의 필요성
  3. 소프트웨어 테스팅 체계 정립 및 테스팅과 품질에 대한 인식 개선
  4. 민간 De facto 표준(ISTQB)의 등장으로 혼란 가중 : 테스팅 표준 간의 호환성 마련
  5. 조직의 테스팅 수행 수준의 객관적 지표 수립 (Gaurantee level)
  6. 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을 갖는 테스팅 수행 다. 테스팅과 품질에 대한 인식 개선, 테스팅 전문가 확보 및 동기부여, 툴을 활용한 표준 프로세스 구축


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

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

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

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

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

  1. SP 품질인증제도의 구성 가. SP 품질인증제도의 품질인증 등급

  2. 개발, 지원, 프로젝트 관리 등 3개 영역의 수준이 인정되면 2레벨

  3. 개발, 지원, 프로젝트 관리, 프로세스 개선, 조직관리 등 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) : 조직의 소프트웨어 개발 프로세스를 개선하고 개발자의 개발 능력을 향상시킴으로써 개발 위험을 통제

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

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


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

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

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

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

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

  1. 개발 방법론 테일러링을 위한 구성도 및 기준 가. 개발 방법론 테일러링을 위한 구성도

  2. 프로젝트 특성, 사용자 요구사항, 프로젝트 팀원들의 기술 수준과 경험을 고려하여 프로젝트 품질관리자는 개발 방법론 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 활동을 통한 업무 재활용 증대

코딩

  1. 코딩 단계의 로드맵

  2. 코딩 오류 가. 메모리 누수(Memory Leak)

  3. 정의 : 메모리가 해제 되지 않고 프로그램에 계속 할당되는 현상
  4. 짧은 프로그램에는 영향이 적지만 장기로 수행되는 시스템에는 치명적인 영향을 줌
  5. 메모리를 계속 할당되다가 메모리가 고갈되어 비정상적으로 정지
  6. 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)을 번갈아하는 상황에서 오류가 많이 발생


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

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

  1. 리팩토링 사례 가. 사례 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'; }

  1. 리팩토링 프로세스 및 주요기법 가. 리팩토링 프로세스

  2. 단일 리팩토링(소규모의 변경)

  3. 코드가 전부 잘 작동하는지 테스트
  4. 전체가 잘 작동하면 다음 리팩토링 단계로 전진
  5. 작동하지 않으면 문제를 해결하고 리팩토링 한 것을 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 클라이언트가 클래스의 어느 특정 기능만을 이용한다면 이러한 기능의 부분 집합을 별도의 인터페이스를 통해 추출

  1. 코드스멜과 리팩토링

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

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

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

인스펙션 대상 체크항목 클래스 전체 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) 자동화의 영역이고 이를 지원하는 도구를 정적 분석 도구라고 함


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

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

테스트

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

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

  1. 테스트 작업 과정

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

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

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

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

항목 화이트 박스 블랙박스 개요 내부 구조 위주 시험 기능 및 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. 소프트웨어 테스트 분류

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

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

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

성능 테스트

○ 인터페이스 테스트

스트레스 테스트

○ ○ 보안 테스트


  1. 개발단계에서 소프트웨어 모듈의 기능성 확인을 위한 단위 테스트 개요 가. 단위 테스트 정의
  2. 모듈 테스트 또는 컴포넌트 테스트라고도 하며 프로그램 내의 각 서브프로그램, 서브루틴, 또는 프로시저, 클래스, 오브젝트 등 프로그램의 최소 구성단위를 테스트 나. 단위 테스트 특징
  3. 화이트박스, 블랙박스 테스트를 모두 적용할 수 있지만 일반적으로 화이트박스 테스트 기법을 적용함
  4. 디버깅 작업이 쉬움
  5. 병렬 처리가 가능하기 때문에 여러개의 모듈들을 동시에 테스트할 수 있음 다. 단위 테스트(Unit Test) 목적
  6. 소프트웨어 모듈, 서브루틴의 사용자 요구사항에 대한 단위 모듈을 테스트하기 위한 단계
  7. 단위 테스트를 통하여 모듈의 오류가 없음을 확인 라. 단위 테스트 단계의 주요 산출물 및 용도 1) 단위 테스트 계획서 : 테스트 범위, 일정, 담당자, 보고방법, 성공요소, 실패요소 2) 단위 테스트 케이스 : 각 모듈에 대한 테스트 케이스, 예측값, 결과, 결함여부 3) 결함보고서 : 단위 테스트 시에 발생된 결함내용, 심각도, 영향도, 수정여부 등 제시
  8. 단위 테스트 환경

  9. 단위 테스트 기법 및 테스트 전략 가. 단위 테스트 기법

  10. 인터페이스 테스트 : 정보 입∙출력의 적절성 시험, 파일속성, 입력 및 출력 매개변수, 요구되는 입∙출력I/O 테스트
  11. 지역 데이터 구조(자료구조) 테스트 : 모듈이 실행되는 동안 자료의 무결성 유지 여부를 시험, 자료형태, 변수 초기화, 자료형태의 일관성 테스트
  12. 경계조건 : 처리를 제한하거나 금지시키기 위해 설정된 경계에서 모듈의 적절한 작동 여부를 시험
  13. 독립경로 : 모듈의 모든 문장은 적어도 한번 실행됨을 확인하기 위한 시험
  14. 실행경로 테스트 : 다른 자료형태 간 비교, 잘못된 루프문 테스트
  15. 에러 핸들링 경로(오류처리) 테스트 : 오류처리 경로, 오류 메시지의 이해용이성, 오류 메시지의 상세정보 제공여부 테스트 나. 단위 테스트 전략

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

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

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

문장검증기준: 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 모든 경우를 테스트

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


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

종류 내용 비점전적 테스트 동시식(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)의 양 고려 - 시스템의 중요한 모듈의 위치, 하드웨어의 가용성, 일정 등을 고려


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

대금지불 지불 x x

미지불

x x 완불 완불 x

x

미완불

x

x 영수증 우송 O O

대금 청구서 우송 O

O

상품 안내서 우송

O

O

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

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

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

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

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

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

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

구성요소 설명 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 버그 분석/추적 실패된 테스트에 대해 버그리포트 추적 및 데이터베이스화

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

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


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

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

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

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

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

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


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

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

  1. 구문/결정/조건 커버리지의 관계도 및 사례 가. 구문/결정/조건 커버리지의 관계도

  2. 구문(Statement) 커버리지는 결정/조건 커버리지가 만족되면 자연스럽게 만족

  3. 결정(Decision)과 조건(Condition) 커버리지는 공통되는 부분도 있지만 그렇지 못한 부분도 존재 나. 구문/결정/조건 사례 If a > 0 and a > b then begin C = b + C print C; end Else begin d = b + C print d; end
  4. 위의 소스코드 중에 분 구문에 해당하는 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) : 결정 포인트내에 있는 모든 개별식 조건의 모든 조합을 고려한 커버리지


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

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

  1. 코드기반(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)'이라 함

  1. 소프트웨어 테스트 품질 확보방안 가. 테스트 자동화 툴 활용 : 테스트 생산성 확보 및 Human Error 최소화, SW품질확보 나. TMM 도입
  2. 소프트웨어 시험조직의 성숙도를 평가하는 모델
  3. 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의 적극적 활용 및 테스트 일정에 따른 테스트 계획의 변경
  • 리스크가 높은 부분에 있어서는 경험많은 인력의 배치
  • 지속적 위험 현행화, 프로세스 기반 업무 정의 및 모니터링

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

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

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

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

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

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

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


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

구분 설명 비고 탐색적 테스팅 (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) 테스터

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

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

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

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

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

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

설명 사례 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) 검사 오라클 - 변경이 있는 경우 전후의 결과값이 같은지 확인하는 것 - 사례 : 모든 상용테스트 자동화 도구에서 사용 라. 테스트 오라클 유형간 비교

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

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

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

  1. SW테스트의 원리, 살충제 패러독스와 오류부재의 궤변의 개념

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

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

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

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


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

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

  1. Mutation Test 개념도 및 Process 가. Mutation Test 개념도

  2. 원본 소스코드에 속성, 서비스, 입력 값, 출력 값을 변경시켜 테스트를 수행하며, 결과값에 대한 비교를 통해 테스트 데이터 신뢰성 검증

  3. 뮤턴트 후의 테스트 결과값이 이전 테스트 결과와 동일할 경우 해당 테스트 데이터의 신뢰성은 낮으며 오류 변별력이 낮다고 판단할 수 있음 나. Mutation Test Process

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

  1. 뮤테이션 테스트의 문제점 및 발전방향 가. 테스트를 디자인하고 테스트 케이스를 작성하는 것에 지나친 노력이 필요하므로 현재까지도 학계에서 논의만 하고 있는 실정이며 실무에서 폭넓게 사용은 못하고 있음. 나. 자동화된 테스트 툴과 변종을 자동적으로 삽입할 수 있는 툴을 사용함으로써 비효율성을 완화시켜야 함 [참조예제]

  2. t1과 t2는 M1(t), M2(t)에서 결과가 같게 나와 좋은 테스트 데이터라고 할 수 없다. 따라서 좀 더 효과적으로 구별해 낼 수 있는 테스트 데이터를 추가해야 한다. t3의 경우는 foo(t)=0, M1(t)=2, M2(t)=1로 모두 다른 결과를 나타내어 좋은 데이터라 할 수 있다.

  3. 비버깅과 뮤테이션의 차이

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


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

필요성 설명 소프트웨어 품질 향상 소프트웨어 품질을 향상하기 위해 산출물 중심의 테스트와 병행하여 프로세스 중심으로 단계별 테스트 활동을 정의하여 관리 최종 소프트웨어 품질을 향상하여 고객 요구사항에 부합하는 제품 생산 제품중심 테스트 보완 소프트웨어 제품중심의 테스트를 소프트웨어 개발 생명주기에 부합하도록 개발 프로세스에 부합할 수 있는 정형화된 테스트 절차를 통해 제품중심의 테스트 보완 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) 결함 예방과 품질제어 활동에 초점, 테스트 프로세스가 정의되고 관리되며, 비용과 효과가 추적되고 감시 테스트 프로세스가 지속적으로 개선되고 조정되며 결함예방과 품질 제어 활동을 수행 이들 활동이 통계적 방법과 다양한 평가 기준에 의해 측정되고 관리자는 지속적인 개선을 유도하기 위해 인프라를 지원하고 동기 부여

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

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

  1. 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. 단계별 성능 테스트 특징

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

기대 효과 단순하게 시스템이나 소프트웨어의 성능 테스트가 아닌 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 별 오라클 결정

  1. 제어 흐름도의 작성

  2. 프로그램 구조를 분석한 제어 흐름도

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

나. Path 2

다. Path 3

라. Path 4

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

다음은 소프트웨어 결함을 식별하고 품질을 확보하기 위해 필요한 시험데이터이다. 가장 적절하지 않은 것은? 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


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

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

  1. 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 : 동작할 각 환경이나 소프트웨어를 검사한다. 또한, 모든 설치 절차, 고객이 이용하는 특별한 설치 소프트웨어, 최종 사용자에게 소프트웨어를 소개하는 모든 문서들을 검사함


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

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

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

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

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

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

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

● 분류 트리 기법(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) 프로그램 내에서 변수들이 값을 할당 받은 지점이나 사용된 지점에 따라, 프로그램의 테스트 경로들을 선택하는 방법이다

유지보수

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

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

다. 목적

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

라. 중요성

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

  1. S/W 변화관리와 유지보수의 핵심인 Lehman 변화 원리 이해 가. Lehman S/W 변화 원리의 개념
  2. S/W는 요구에 의해 계속적으로 변경되며, 변경에 따른 복잡성, 프로그램의 고유한 변경추세, S/W조직 생산성의 일관성, S/W 각 버전의 변화에 대한 일관성을 제시한 S/W 변화의 원리 나. Lehnam의 S/W 변화 원리의 중요성
  3. S/W 변화의 특성을 이해하고 유지보수, 변경관리, 형상관리, 품질통제의 중요 모델로 반영
  4. 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) 소프트웨어를 변경한 후에도 여전히 같은 기능을 하고 있음을 확인하기 위한 테스트 변경에 의하여 영향을 받는 부분만 다시 테스트

  1. 소프트웨어 개발과 유지보수 비용의 비교
  2. 소프트웨어 개발 : 코딩 중심의 작업
  3. 유지보수 : 이해 중심의 작업

  4. 개발 비용 : 분석, 설계에서 서서히 올라가다가 구현 단계에 최고점에 달하고 테스팅 이후 다시 낮아짐

  5. 유지보수 비용 : 이해 단계에서(분석, 설계) 많이 비용이 들고 실제 코드를 수정한 단계(구현)에서는 아주 적게 들며 적은 비용으로 테스팅 가능
  6. 효율적인 유지보수를 위한 3R 가. S/W 3R의 정의
  7. 완성된 소프트웨어 실체를 기반으로 역공학(Reverse Engineering), 재공학(Re-engineering), 재사용(Re-use)을 통해 소프트웨어 생산성을 극대화하는 기법
  8. Repository(소프트웨어 저장소) 기반 나. S/W 3R의 필요성
  9. 소프트웨어 유지보수(CASE 도구 사용) 효율성 제고 및 비용 절감
  10. 소프트웨어 개발 생산성 향상
  11. 소프트웨어 이해, 변경, 테스트 용이
  12. 소프트웨어 변경 요구사항에 대한 신속한 대처 가능
  13. 소프트웨어 위기(소프트웨어 개발의 대형화, 복잡화, Life-Cycle 감소) 극복 다. 소프트웨어 3R의 개념도

  14. 역공학 : 구현된 것을 분석하여 설계단계로 요구사