1챕터 마지막
07 객체지향 구현
Section 1. 객체지향 설계
1. 객체지향 (Object Oriented Programming-OOP)
⑴ 객체지향 개념
- 현실 세계의 유형, 무형의 모든 대상을 객체(Object)로 나누고, 객체의 행동(method)과 고유한 값(Attribute)을
정의하여 설계하는 방법
⑵ 객체지향 구성요소
■ 클래스 (Class)
- 유사한 종류의 유형/무형의 존재를 속성과 연산을 정의해서 만든 틀
■ 객체 (Object)
- 클래스의 인스턴스
■ 속성 (Attribute)
- 객체들이 가지고 있는 고유한 데이터를 단위별로 정의한 것
■ 메서드 (Method)
- 어떤 특정한 작업을 수행하기 위한 명령문의 집합
■ 메시지 (Message)
- 객체에게 어떤 행위를 하도록 지시
⑶ 객체지향언어의 특징
- 캡슐화(Encapsulation)
- 정보은닉(Information Hiding)
- 상속(Inheritance)
- 다형성(Polymorphism)
- 추상화(Abstraction)
⑷ 객체지향 설계원칙(SOLID)
■ 단일 책임 원칙(SRP, Single responsibility principle)
- 한 클래스는 하나의 책임만을 가져야한다.
■ 개방 폐쇄 원칙(OCP, Open-closed principle)
- 확장에는 열려 있고, 수정에는 닫혀 있어야 한다.
■ 리스코프 치환 원칙(LSP, Liskov substitution principle)
- 자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있어야 한다.
■ 인터페이스 분리 원칙(ISP, Interface Segregation Principle)
- 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다.
■ 의존성 역전 원칙(DIP, Dependency Inversion Principle)
- 의존 관계를 맺을 때 자주 변화하는 것보다, 변화가 거의 없는 것에 의존해야 한다.
2. 디자인패턴
⑴ 디자인 패턴(Design Pattern) 개념
- 객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들에 대해 재사용할 수 있도록 만들어놓은 패턴들의
모음
⑵ 디자인 패턴 구조
- 패턴의 이름과 유형
- 문제 및 배경
- 솔루션
- 결과
- 사례
- 샘플 코드
⑶ GoF 디자인 패턴
■ GoF(Gang of Four) 의 디자인 패턴
- 에리히 감마(Erich Gamma), 리차드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시디스(John
Vissides) 에 의해 개발 영역에서 디자인 패턴을 구체화 하고 체계화 시킴
■ Gof 디자인 패턴 분류
생성 패턴
- 객체 생성과 관련한 패턴
- 객체 생성에 있어서 프로그램 구조에 영향을 크게 주지 않는 유연성 제공
구조 패턴
- 클래스나 객체를 조합해서 더 큰 구조를 만드는 패턴
행위 패턴
- 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴
생성(Creational) 패턴
-
Abstract Factory
Builder
Factory Method
Prototype
Singleton
구조(Structural) 패턴
-
행위(Behavioral) 패턴
-
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
08 애플리케이션 테스트 관리
Section 1. 애플리케이션 테스트케이스 설계
1. 소프트웨어 테스트
⑴ 소프트웨어 테스트의 개념
- 구현된 소프트웨어에서, 사용자가 요구하는 기능의 동작과 성능, 사용성, 안정성 등을 만족하기 위하여
소프트웨어의 결함을 찾아내는 활동
⑵ 소프트웨어 테스트의 필요성
- 오류 발견 관점
- 오류 예방 관점
- 품질 향상 관점
⑶ 소프트웨어 테스트의 기본 원칙
- 테스팅은 결함이 존재함을 밝히는 활동이다.
- 완벽한 테스팅은 불가능하다.
- 테스팅은 개발 초기에 시작해야 한다.
- 결함 집중(Defect Clustering) - 파레토 법칙
- 살충제 패러독스(Presticide Paradox)
- 테스팅은 정황(Context)에 의존한다.
- 오류-부재의 궤변(Absence of Errors Fallacy)
⑷ 테스트 산출물
■ 테스트 계획서
■ 테스트 케이스
- 케이스를 작은 단위로 나누어 각 단위의 입력 값, 테스트 조건, 기대 결과를 기술한다.
■ 테스트 시나리오
- 테스트를 위한 절차를 명세한 문서
■ 테스트 결과서
- 테스트 결과를 정리한 문서
2. 테스트 오라클
⑴ 테스트 오라클의 개념
- 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법 및 활동
⑵ 테스트 오라클의 유형
- 참 오라클 (True)
- 샘플링 오라클 (Sampling)
- 휴리스틱 오라클 (Heuristic)
- 일관성 검사 오라클 (Consistent)
3. 테스트 레벨
4. 소프트웨어 테스트 기법
⑴ 프로그램 실행 여부
① 정적 테스트
- 소프트웨어의 실행 없이 소스 코드의 구조를 분석하여 논리적으로 검증하는 테스트
- 경로 분석, 제어 흐름 분석, 데이터 흐름 분석 등을 수행
② 동적 테스트
- 소프트웨어를 실행 하여 실제 발생하는 오류를 발견하여 문제를 해결하는 분석 기법
- 다양한 운영 환경에서 소프트웨어를 분석
⑵ 테스트 기법
① 화이트박스 테스트
- 소프트웨어의 내부 구조와 동작을 검사하는 테스트 방식
- 화이트박스 테스트 기법
기법
문장 검증
선택(분기) 검증
설명
검증 방법
프로그램의 모든 문장을 한번 수행하여 검증
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,3,5,6,1
x>1 or y<10 일 경우
조건 검증
조건이나 반복문 내 조건식을 검사
x>1 조건과 y<10
모두 테스트
② 기초 경로 검사 (Basic Path Test)
- McCabe가 제안한 것으로 대표적인 화이트박스 테스트 기법
- 계산식 : V(G)=E-N+2
③ 블랙박스 테스트
- 프로그램의 외부 사용자 요구사항 명세를 보면서 테스트, 주로 구현된 기능을 테스트
- 블랙박스 테스트 기법
기법
동등 분할 기법 (Equivalence Partitioning Testing)
경계값 분석 (Boundary Value Analysis)
원인-효과 그래프 검사 (Cause-Effect Graphing Testing)
오류 예측 검사 (Error Guessing)
비교 검사 (Comparison Testing)
설명
- 입력 자료에 초점을 맞춰 테스트 케이스를 만들어 검사하는 방법
- 입력 데이터의 영역을 유사한 도메인별로 유효값과 무효값을 그룹핑하여 나누어서
검사
- 입력 값의 중간값보다 경계값에서 오류가 발생할 확률이 높다는 점을 이용해
입력 조건의 경계값을 테스트 케이스로 선정한다.
- 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음
효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
- 과거의 경험이나 테스터의 감각으로 테스트하는 기법
- 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지
테스트하는 기법이다.
⑶ 테스트에 대한 시각
① 검증(Verification)
- 소프트웨어의 개발 과정을 테스트
- 올바른 소프트웨어가 만들어지고 있는지 검증
② 확인(Validation)
- 완성된 소프트웨어의 결과를 테스트
- 완성된 소프트웨어가 정상적으로 동작하는지 확인
- 완성된 소프트웨어가 사용자의 요구사항을 만족하는지 확인
⑷ 테스트 목적
■ 회복(Recovery) 테스트
- 시스템에 고의로 실패를 유도하고 시스템이 정상적으로 복귀하는지 테스트
■ 안전(Security) 테스트
- 불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스코드 내의 보안적인 결함을 미리 점검하는
테스트
■ 강도(Stress) 테스트
- 시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정상적으로 작동되는지를 검증하는 테스트
■ 성능(Performance) 테스트
- 사용자의 이벤트에 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는
속도 등을 테스트
■ 구조(Structure) 테스트
- 시스템의 내부 논리 경로, 소스코드의 복잡도를 평가하는 테스트
■ 회귀(Regression) 테스트
- 변경 또는 수정된 코드에 대하여 새로운 결함 발견 여부를 평가하는 테스트
■ 병행(Parallel) 테스트
- 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트
⑸ 테스트 종류
① 명세 기반 테스트
Ÿ 주어진 명세를 빠짐없이 테스트 케이스로 구현하고 있는지 확인하는 테스트
② 구조 기반 테스트
Ÿ 소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
③ 경험 기반 테스트
Ÿ 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 한, 직관과 기술 능력을 기반으로 수행하는 테스트
5. 테스트 커버리지
⑴ 테스트 커버리지의 개념
- 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준
- 테스트를 얼마나 수행했는지 측정하는 기준
⑵ 테스트 커버리지 유형
① 기능 기반 커버리지
- 테스트 대상 애플리케이션의 전체 기능을 모수로 설정하고, 실제 테스트가 수행된 기능의 수를 측정하는 방법
② 라인 커버리지(Line Coverage)
- 애플리케이션 전체 소스 코드의 Line 수를 모수로 테스트 시나리오가 수행한 소스 코드의 Line 수를 측정하는
방법
③ 코드 커버리지(Code Coverage)
- 소프트웨어 테스트 충분성 지표 중 하나로 소스 코드의 구문, 조건, 결정 등의 구조 코드 자체가 얼마나
테스트되었는지를 측정하는 방법
Section 2. 애플리케이션 통합 테스트
1. 결함관리 도구
⑴ 결함관리 도구의 개념
- 각 단계별 테스트 수행 후 발생한 결함의 재발 방지를 위해, 유사 결함 발견 시 처리 시간 단축을 위해 결함을
추적하고 관리할 수 있게 해주는 도구
⑵ 결함관리 프로세스
- 에러 발견
- 에러 등록
- 에러 분석
- 결함 확정
- 결함 할당
- 결함 조치
- 결함 조치 검토 및 승인
⑶ 결함 추이 분석
■ 결함 관리 측정 지표
- 결함 분포 : 각 애플리케이션 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 수를 측정하여 결함의 분포
를 분석할 수 있다.
- 결함 추세 : 테스트 진행 시간의 흐름에 따른 결함의 수를 측정하여 결함 추세를 분석할 수 있다.
- 결함 에이징 : 등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정하여 분석할 수 있다.
⑷ 결함 관리 도구 종류
■ S/W 테스트 관리
- TestLink, GanttProject, OpenProj, Redmine
■ 결함 추적 관리
- Mantis, Bugzilla, Trac
2. 테스트 자동화 도구
⑴ 테스트 자동화 도구의 개념
- 테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현함으로써, 테스트 시간 단축과 인력
투입 비용을 최소화하는 한편, 쉽고 효율적인 테스트를 수행할 수 있는 방법
⑵ 테스트 자동화 도구 유형
① 정적 분석 도구(Static Analysis Tools)
- 정적 분석 도구는 만들어진 애플리케이션을 실행하지 않고 분석하는 방법
② 테스트 실행 도구(Test Execution Tools)
- 테스트를 위해 작성된 스크립트를 실행
③ 성능 테스트 도구(Performance Test Tools)
- 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트를
수행함으로써 성능 목표를 달성하였는지를 확인하는 도구
④ 테스트 통제 도구(Test Control Tools)
- 테스트 관리 도구 : 테스트 계획 및 관리
- 형상 관리 도구 : 테스트 수행에 필요한 데이터와 도구를 관리
- 결함 추적/관리 도구 : 테스트에서 발생한 결함에 대해 관리하거나 협업을 지원
⑤ 테스트 장치(Test Harness)
구성요소
설명
테스트 드라이버 (Test Driver)
- 테스트 대상 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의
테스트 스텁 (Test Stub)
테스트 슈트 (Test Suites)
테스트 케이스 (Test Case)
테스트 스크립트 (Test Script)
목 오브젝트 (Mock Object)
결과를 도출하는 등 상향식 테스트에 필요하다.
- 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로 하향식 테스트에
필요하다.
- 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합을 말한다.
- 입력 값, 실행 조건, 기대 결과 등의 집합을 말한다.
- 자동화된 테스트 실행 절차에 대한 명세를 말한다.
- 사용자의 행위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위를 수행하는
객체를 말한다.
3. 통합 테스트
⑴ 통합 테스트의 개념
- 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법
⑵ 통합 테스트 수행 방법의 분류
Section 3. 애플리케이션 성능 개선
1. 애플리케이션 성능 저하 원인
⑴ 데이터베이스 관련 성능 저하
- 데이터베이스 락(DB Lock)
- 불필요한 패치(DB Fetch)
- 연결 누수(Connection Leack)
⑵ 내부 로직으로 인한 성능 저하 원인
⑶ 외부 호출로 인한 성능 저하
2. 애플리케이션 성능 분석
⑴ 애플리케이션 성능 분석 지표
- 처리량(Throughput)
- 응답 시간(Response Time)
- 경과 시간(Turn Around Time)
- 자원 사용률(Resource Usage)
⑵ 성능 분석 도구
■ JMeter
- HTTP, FTP등 다양한 프로토콜을 지원하는 부하 테스트 도구
■ LoadUI
- 서버 모니터링, Drag&Drop 등 사용자 편리성이 강화된 도구
■ OpenSTA
- HTTP, HPPTS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구
⑶ 모니터링 도구
■ Scouter
- 단일 뷰 통합/실시간 모니터링
■ NMon
- 리눅스 서버 자원에 대한 모니터링 도구
■ Zabbix
- 웹기반 서버, 서비스, 애플리케이션 모니터링 도구
■ Jeniffer
- 애플리케이션에서 서버로 유입되는 트랜잭션 수량, 처리시간, 응답시간, 자원 활용율 등을 모니터링
3. 정형 기술 검토회의(FTR, Formal Technical Review)
⑴ FTR의 개념
- 소프트웨어 엔지니어가 수행하는 소프트웨어 품질보증 활동
- 개발단계에서 제작되는 문서나 프로그램의 문제점을 찾고, 문제해결을 촉구하는 일반적인 용어
- S/W 개발 산출물을 대상으로 오류를 발견하기 위한 공식적인 활동
⑵ FTR의 목적
- 산출물 요구사항 일치여부
- 소프트웨어가 미리 정한 기준에 따라 표현 되었는가를 확인
- 소프트웨어의 표현에 대한 기능, 논리적 오류
- 프로젝트를 보다 관리하기 쉽게 만든다.
4. 소스코드 품질 분석
⑴ 동료 검토(Peer Review)
- 2~3명이 진행하는 리뷰의 형태
- 작성자가 코드를 설명하고 이해 관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행하는 기법
⑵ 워크스루(Walkthrough)
- 계획된 개발자 검토 회의
- 검토 자료를 회의 전에 배포해서 사전검토 한 후 짧은 시간 동안 회의를 진행하는 형태
⑶ 인스펙션(Inspection)
- 공식적 검사 회의
- 작업자 외 다른 전문가가 검사하는 가장 공식적인 리뷰 기법
5. 소스코드 품질 분석 도구
구분
도구명
PMD
주로 Java에서 사용하지만, Javascript, PLSQL, XML 등의 언어도 지원
checkstyle
자바 코드에 대한 소스 코드 표준 준수 검사, 다양한 개발 도구에 통합 가능
정적 분석 도구
SonarQube
중복코드, 복잡도, 코딩 설계 등을 분석하는 소스 분석 통합 플랫폼
cppcheck
ccm
C, C++코드에 대한 메모리 누수, 오버플로우 등 문제 분석
다양한 언어의 코드 복잡도 분석 도구
cobertura
자바 언어의 소스 코드 복잡도 분석 및 테스트 커버리지 측정
동적 분석 도구
Avalanche
프로그램에 대한 결함 및 취약점 분석
Valgrind
프로그램 내 존재하는 메모리 및 스레드 결함 등 분석
6. 애플리케이션 성능 개선하기
⑴ 코드 최적화의 개념
- 주어진 코드에 대해 같은 작업을 수행 하면서, 실행 시간을 줄이거나 메모리를 줄이는 것
⑵ 코드 스멜(Code Smell)
- 같은 코드가 여러 곳에 존재하는 중복된 코드로 코드 스멜(Code Smell)이 발생
용어
스파게티 코드 (spaghetti code)
외계인 코드
설명
- 소스 코드가 복잡하게 얽힌 모습을 스파게티의 면발에 비유한 표현이다.
- 아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램
코드이다.
⑶ 리팩토링
- 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법
⑷ 클린코드
- 의존성을 최소로 하고 사람이 이해할 수 있는 가독성, 목적성이 뛰어난 명확한 코드
■ 클린코드 작성원칙
- 가독성
- 단순성
- 의존성 배제
- 중복성 최소화
- 추상화
09 소프트웨어 유지보수
Section 1. 소프트웨어 유지보수
1. 소프트웨어 유지보수
⑴ 소프트웨어 유지보수의 개념
- 개발 완료 시점부터 폐기될 때까지, 지속적으로 수행하는 작업
- 소프트웨어의 수명을 연장하기 위한 활동
⑵ 유지보수가 어려운 이유
- 업무 프로세스와 구축된 시스템을 이해해야 함
- 유지보수 계약이 개발과 계획과 별개인 경우 시간이 지나면서 소프트웨어 구조와 가독성이 떨어짐
2. 유지보수의 구분
⑴ 수정 보수(Corrective Maintenance)
- 소프트웨어 구축 시 테스트 단계에 미처 발견하지 못한 잠재적인 오류를 찾아 수정한다.
⑵ 적응 보수(Adaptive Maintenance)
- 운영체제, 하드웨어와 같은 프로그램 환경변화에 맞추기 위해 수행하는 유지보수
⑶ 향상 보수(Perfective Maintenance)
- 기존 기능과 다른 새로운 기능을 추가하거나, 기존 기능을 개선
⑷ 예방 보수(Preventive Maintenance)
- 장래에 유지보수성 또는 신뢰성을 보장하기 위해 선제적으로 하는 유지보수
3. 유지보수 관련 용어
■ 레거시 시스템(legacy system)
- 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어 등을 말한다.
- 더이상 쓰이지 않더라도 현대의 기술에 영향을 주는 경우도 포함한다.
■ 외계인 코드(Alien Code)
- 아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램 코드
- 프로그램 문서화(Documentation)을 통해 외계인 코드를 방지 가능
■ 스파게티 코드(Spaghetti Code)
- 복잡한 프로그래밍 소스 코드
- 작동 자체는 제대로 하거나 하는 것처럼 보이지만, 추후 유지보수가 매우 어려워진다.
10 제품 소프트웨어 패키징
Section 1. 국제 표준 제품 품질 특성
1. 제품 품질 국제 표준
⑴ 제품 품질 국제 표준의 개념
- 소프트웨어 개발 공정 각 단계에서 산출되는 제품이 사용자 요구를 만족하는지 검증하기 위한 국제 표준
⑵ 소프트웨어 품질 관련 국제 표준
① ISO/IEC 9126 의 소프트웨어 품질 특성
품질 특성
기능성 (Functionality)
신뢰성 (Reliability)
사용성 (Usability)
효율성 (Efficiency)
유지보수성 (Maintainability)
이식성 (Portability)
설명
- 소프트웨어가 특정 조건에서 사용될 때, 명시된 요구와 내재된 요구를 만족하는 기능에
대한 소프트웨어 제품의 능력
- 부특성 : 적합성, 정확성, 상호 운용성, 보안성, 준수성
- 소프트웨어가 명세된 조건에서 사용될 때, 성능 수준을 유지할 수 있는 소프트웨어
제품의 능력
- 부특성 : 성숙성, 결함 허용성, 복구성
- 사용자에 의해 이해 이해되고, 학습되고, 사용되고, 선호될 수 있는 소프트웨어 제품의
능력
- 부특성 : 이해성, 학습성, 운영성, 선호도, 준수성
- 사용되는 자원의 양에 따라 요구된 성능을 제공하는 소프트웨어 제품의 능력
- 부특성 : 시간 반응성, 자원 활용성, 준수성
- 소프트웨어 제품이 변경되는 능력
- 소프트웨어의 수정, 개선 등이 포함된다.
- 부특성 : 분석성, 변경성, 안정성, 시험성, 준수성
- 현재 환경에서 다른 환경으로 이전될 수 있는 소프트웨어 제품의 능력
- 부특성 : 적응성, 설치성, 공존성, 대체성, 준수성
② ISO/IEC 14598 평가 특성
평가 특성
설명
반복성 (Repetability)
- 특정 제품에 대해 동일 평가자가 동일 사양에 대해 평가 했을 때 동일한 결과가 나와야 한다.
재현성 (Reproducibility)
공정성 (Impartiality)
효율성 (Efficiency)
- 특정 제품에 대해 다른 평가자가 동일 사양에 대해 평가 했을 때 동일하다고 여길 수 있는 결과가 나와야 한다.
- 평가가 특정 결과에 편향되지 않아야 한다.
- 평가 결과가 평가자의 감정이나 의견에 의해 영향을 받지 않아야 한다.
③ ISO/IEC 12119
- 패키지 SW 품질 요구사항 및 테스트
④ ISO/IEC 25000
- ISO 9126과 ISO 14598, ISO 12119, ISO 15288 표준을 5개 영역 중심으로 통합한 소프트웨어 평가 모델
국제 표준
2. 프로세스 품질 국제 표준
⑴ 프로세스 품질 국제 표준의 개념
- 소프트웨어 개발 프로세스 등 소프트웨어 관련 업체의 프로세스 관리능력을 평가하고 프로세스를 개선하는데
활용할 수 있는 표준
⑵ 국제 프로세스 품질 표준
① ISO/IEC 12207 구성
생명주기 프로세스
세부 프로세스
기본 생명주기 프로세스
- 획득, 공급, 개발, 운영, 유지보수
지원 생명주기 프로세스
- 문서화, 형상관리, 품질보증, 검증, 확인, 합동검토, 감사, 문제해결
조직 생명주기 프로세스
- 관리, 기반구조, 개선, 교육훈련
② ISO/IEC 15504(SPICE)
■ SPICE 프로세스 능력 수준
수준
단계
설명
0
불안정 단계(Incomplete)
1
수행 단계(Performed)
프로세스 수행 및 목적 달성
2
관리 단계(Managed)
프로세스 수행 계획 및 관리
3
확립 단계(Established)
표준 프로세스의 사용
4
예측 단계(Predictable)
프로세스의 정량적 이해 및 통제
5
최적화 단계(Optimizing)
미구현 또는 목표 미달성
프로세스의 지속적인 개선
③ CMM(Capability Maturity Model)
- 소프트웨어 개발 업체들의 업무능력평가 기준을 세우기 위한 평가 모형
■ CMM 성숙도 5단계
수준
단계
1
초기 단계(Initial)
2
반복 단계(Repeatable)
설명
- 소프트웨어를 개발하고 있으나 관리는 하고 있지 않은 상태
- 프로세스의 성과를 예측할 수 없는 상태
- 이전의 성공적인 프로젝트의 프로세스를 반복하고 있는 상태
- 같은 것을 반복적으로 실행하며 어느 정도의 통계적 관리가 가능한 상태
- 프로세스 작업이 잘 정의/이해되고, 프로세스 데이터에 의한 프로젝트
3
정의 단계(Defined)
관리도 실행하고 있는 상태
- 프로세스의 기초가 정립되어 계속 진보되고 있는 상태
- 프로세스 성과를 측정/분석하여 개선시키고, 이를 바탕으로 관리하고
4
관리 단계(Managed)
있는 상태
- 정량적 프로세스 관리, 소프트웨어 품질 관리
5
최적화 단계(Optimizing)
- 질적, 양적으로 지속적인 개선이 이루어지고 있는 상태
④ CMMi(Capability Maturity Model Integration)
- 시스템과 소프트웨어 영역을 하나의 프로세스 개선 툴로 통합시켜 기업의 프로세스 개선 활동에 광범위한
적용성을 제공하는 모델
■ CMMi 성숙도 5단계
수준
단계
1
초기 단계(Initial)
설명
- 구조화된 프로세스를 갖고 있지 않는 조직
- 기본적인 프로세스를 갖고 있는 조직
2
관리 단계(Managed)
- 기본 프로세스에 따라 업무가 수행되고 기본적인 관리 활동들로부터
구체적인 특정 영역으로 프로세스의 체계가 확대 발전하는 조직
3
정의 단계(Defined)
- 조직 차원의 표준 프로세스를 보유하고 있으며 프로젝트를 수행할
경우 프로젝트의 특성에 따라 적절하게 조정하여 사용
정량적 관리 단계
4
(Quantitatively
- 프로세스들을 통계적이고 정략적으로 관리하는 조직
Managed)
5
최적화 단계(Optimizing)
- 질적, 양적으로 지속적인 개선이 이루어지고 있는 상태
Section 2. 제품 소프트웨어 패키징
1. 애플리케이션 패키징
⑴ 애플리케이션 패키징의 개념
- 개발이 완료된 제품 소프트웨어를 고객에게 전달하기 위한 형태로 패키징하고, 설치와 사용에 필요한 제반
절차 및 환경 등 전체 내용을 포함하는 매뉴얼을 작성하는 활동
⑵ 사용자 중심의 패키징 작업
- 사용자 실행 환경의 이해
- 사용자 관점에서의 패키징 고려 사항
⑶ 애플리케이션 패키징 수행 순서
- 기능 식별
- 모듈화
- 빌드 진행
- 사용자 환경 분석
- 패키징 적용 시험
- 패키징 변경 개선
2. 릴리즈 노트
⑴ 릴리즈 노트의 개념
- 소프트웨어 제품과 함께 배포되는 문서들을 말한다.
⑵ 릴리즈 노트 작성 항목
작성항목
설명
Header
- 문서 이름(릴리스 노트 이름), 제품 이름, 버전 번호, 릴리즈 날짜, 참고 날짜, 노트 버전 등
개요
- 제품 및 변경에 대한 간략한 전반적 개요
목적
- 릴리스 버전의 새로운 기능목록과 릴리스 노트의 목적에 대한 간략한 개요.
- 버그 수정 및 새로운 기능 기술.
이슈 요약
- 버그의 간단한 설명 또는 릴리즈 추가 항목 요약
재현 항목
- 버그 발견에 따른 재현 단계 기술
수정/개선 내용
- 수정 / 개선의 간단한 설명 기술
사용자 영향도
- 버전 변경에 따른 최종 사용자 기준의 기능 및 응용 프로그램 상의 영향도 기술
SW 지원 영향도
노트
- 버전 변경에 따른 SW의 지원 프로세스 및 영향도 기술
- SW 및 HW Install 항목, 제품, 문서를 포함한 업그레이드 항목 메모
면책 조항
- 회사 및 표준 제품과 관련된 메시지. 프리웨어, 불법 복제 방지, 중복 등 참조에 대한
고지 사항
연락 정보
- 사용자 지원 및 문의 관련한 연락처 정보
3. DRM
⑴ DRM(Digital Rights Management)의 개념
- 각종 디지털 콘텐츠의 불법적인 사용을 제한하고, 승인된 사용자의 콘텐츠 사용을 저작권 소유자의 의도에
따라 제어하는 기술
⑵ DRM의 구성 및 흐름
⑶ DRM 사용 규칙 제어 기술
① 콘텐츠 식별 체계 (Identificayion)
- 디지털 콘텐츠에 고유 식별 번호를 부여하여 관리하고 운영
- 대표적으로 DOI(Digital Object Identifier), URI 가 있다.
② 메타데이터 (Meta Data)
- 콘텐츠에 관한 구조화된 데이터
- 콘텐츠의 속성정보
③ 권리표현기술 (Right Expression)
- 콘텐츠에 대한 규칙 설정
- 어느 사용자가 어떠한 권한과 어떠한 조건으로 콘텐츠를 이용할 수 있는지 정의
- 콘텐츠의 사용조건(기간, 횟수) 등에 의해 사용이 제한 될 수 있고, 주로 XML 기반으로 권한 표현 언어가 개발
- XrML(eXtensible rights mark-up language) 기술이 대표적
④ 권리표현 종류
권리표현 종류
설명
Render Permission
사용자에게 콘텐츠가 표현되고 이용되는 권리 형태를 정의
Transport Permission
사용자들 간에 권리의 교환이 이루어지는 권리 형태를 정의
Derivative Permission
콘텐츠의 추출 변형이 가능한 권리 형태를 정의
⑷ 저작권 보호 기술
① 암호화 기술
- 특정 키를 가진 사용자만이 해당 콘텐츠를 사용할 수 있도록 한다.
- 암호화 키와 복호화 키가 서로 다른 비대칭키 방식과 두 키가 동일한 대칭키 방식 있다.
② 위변조 방지(Tamper-proofing)
- 콘텐츠에 승인되지 않은 조작이 가해졌을 때, 위변조 사항을 감지할 수 있도록 하고, 오류 동작을 일으키게끔
하는 기술
- 부정 조작에 대한 방어 기술
③ 워터마킹(Watermarking)
- 콘텐츠에 저작권 정보를 은닉하여, 향후 저작권 분쟁이 일어날 경우, 추척을 통해 저작권자를 확인할 수 있게
해주는 기술
- 워터마킹(Watermarking), 핑거프린팅(Fingerprinting) 으로 구분
관점
워터마킹
핑거프린팅
목적
불법 복제 방지
불법 유통 방지
삽입정보
저작권 정보
저작권 정보 + 구매자 정보
컨텐츠 변화 시점
최초 저작 시점
구매시점 마다
취약점
불법 유통
공모 공격
⑸ DRM 구성요소
구성요소
암호화 (Encryption)
키 관리 (Key Manangement)
암호화 파일 생성 (Packager)
식별 기술 (Identification)
저작권 표현 (Right Expression)
정책 관리 (Policy management)
크랙 방지 (Tamper Resistance)
설명
- 콘텐츠 및 라이선스를 암호화하고, 전자 서명을 할 수 있는 기술
- PKI, Symmetric/Asymmetric Encryption, Digital Signature
- 콘텐츠를 암호화한 키에 대한 저장 및 배포 기술
(Centralized, Enveloping)
- 콘텐츠를 암호화된 콘텐츠로 생성하기 위한 기술
- Pre-packaging, On-the-fly Packaging
- 콘텐츠에 대한 식별 체계 표현 기술
- DOI, URI
- 라이선스의 내용 표현 기술
- XrML/MPGE-21 REL, ODRL
- 라이선스 발급 및 사용에 대한 정책표현 및 관리기술
- XML, Contents Management System
- 크랙에 의한 콘텐츠 사용 방지 기술
- Secure DB, Secure Time Management, Encryption
인증
- 라이선스 발급 및 사용의 기준이 되는 사용자 인증 기술
(Authentication)
- User/Device Authentication, SSO, DiGital Certificate
Section 3. 제품 소프트웨어 매뉴얼 작성
1. 제품 소프트웨어 매뉴얼 작성
⑴ 제품 소프트웨어 매뉴얼 개념
- 사용자가 제품 구매 후 최초 설치 시 참조하게 되는 매뉴얼
- 제품 소프트웨어 소개, 설치 파일, 설치 절차 등이 포함
⑵ 제품 소프트웨어 설치 매뉴얼
구성 요소
설명
- 제품 소프트웨어의 주요 기능 및 UI 설명
- UI 및 화면 상의 버튼, 프레임 등을 도식화하여 설명
제품 소프트웨어 개요
- 제품 소프트웨어를 설치하기 위한 관련 파일 설명
- 설치 구동을 위한 exe 실행
- ini나 log 파일 같은 관련 파일
설치 관련 파일
설치 절차
- 소프트웨어 설치 방법을 순서대로 상세히 설명
설치 아이콘
- Windows 구동용 설치 아이콘 설명
프로그램 삭제
- 해당 소프트웨어 삭제 시 원래대로 삭제하는 방법을 설명
설치 환경
- CPU, Memory, OS 등 환경설명
설치 버전 및 작성자
- 소프트웨어 릴리즈 버전 및 작성자 정보
고객 지원 방법 및 FAQ
- 실제 설치 시 자주 발생하는 어려움들을 FAQ로 정리
- 유선 및 E-mail, Website URL
⑶ 제품 소프트웨어 사용자 매뉴얼
작성 항목
설명
목차 및 개요
- 매뉴얼 전체의 내용을 순서대로 요약
- 제품 소프트웨어의 주요 특징에 대해 정리
- 사용자 매뉴얼에서의 구성과 실행 방법, 메뉴에 대한 설명을 비롯하여 사용법,
각 항목에 따른 점검 기준, 그리고 설정 방법 등에 대해 기술함
문서 이력 정보
사용자 매뉴얼의 주석
- 사용자 매뉴얼 변경 이력 정보
- 주의 사항: 사용자가 반드시 숙지해야 하는 중요한 정보의 주석 표시
- 참고 사항: 특별한 사용자 환경 및 상황에 대한 내용의 주석 표시
기록 항목
- 제품명칭, 모델명, 기록 항목에 대한 문서 번호, 제품 번호, 구입 날짜 등을 기재
기본 사항
- 소프트웨어 개요, 사용방법, 모델/버전별 특징, 기능 및 인터페이스 특징, 구동
환경 등을 기재
고객 지원 방법 및 FAQ
- 소프트웨어 사용시 자주 발생하는 어려움들을 FAQ로 정리
- 유선 및 E-mail, Website URL
준수 정보 & 제한 보증
- 시리얼 보존, 불법 등록 사용금지 등의 준수 사항 권고
- 저작권 정보 관련 작성