HowToFish

IEEE 1471 프레임워크

• 소프트웨어 아키텍쳐 기술(description) 프레임워크

• 시스템은 하나의 아키텍처를 가진다
• 시스템은 어떤 환경 속에서 미션을 수행한고 이 환경은 언제나 제약 조건을 가지고 있다
• 시스템을 둘러싸고 있는 많은 이해관계자가 있다
• 따라서, 제약된 환경에서 이해관계자의 요구사항을 만족시키는 아키텍처가 필요함.

FP측정 유형 및 절차

• DET(Date Element Type) : 사용된 Field나 테이블의 속성 수.
• FTR(File Type Reference) : 참조 또는 변경하는 ILF(내부 논리 파일)의 수.
• RET(Record Element Type) : Table의 숫자로 이해하면 쉬움
• ILF(Internal Logical File) : 측정 범위 내에 있는 논리적인 데이터
• EIF(External Interface File) : 측정 범위 내에서 사용하지만, 외부에 있는 데이터
• EI(External Input) : 입력/수정/삭제 기능
• EO(External Output) : 수학적인 수식 이나 계산식을 통한 가공후 표시
• EQ(External inQuiry) : 가공 없이 표시

• SAAM (Software Architecture Analysis Method)
• ATAM (Architecture Trade-off Analysis Method)
• CBAM (Cost Benefit Analysis Method)
• ARID (Architecture Reviews for Intermediate Design)
• ADR (Active Design Review)

ITIL - Service Delivery Process

COCOMO 모델 프로젝트 유형별 산정 방법

[계산식 암기]

Function Point 

- 기술적 복잡도 산정을위한 14개 복잡도 요소

1. 데이터 통신 (Data Communications)
2. 분산 데이터 처리(Distributed data processing)
3. 성능(Performance)
4. 컴퓨터 자원 제한성(Heavily used configuration)
5. 트랜잭션 비율(Transaction rate)
6. 온라인 데이터 입력(Online data entry)
7. 최종 사용자 효율성(End user efficiency)
8. 온라인 갱신(Online update)
9. 복잡한 처리(처리복잡도, Complex processing)
10. 재사용성(Reusability)
11. 설치용이성(Installation ease)
12. 운영용이성(Operational ease)
13. 다중 사이트(Multiple sites)
14. 변경 촉진(변경용이성, Facilitate change)

- 복잡도 측정 척도

 0. 존재하지 않거나 영향이 없음(Not present, or no influence)

 1. 우연한 영향(Incidental influence)

 2. 보통의 영향(Moderate influence)

 3. 평균적인 영향(Average influence)

 4. 중대한 영향(Significant influence)

 5. 지속적으로 강력한 영향(Strong influence throughout)

ITIL -Service Support

ISO 29119 구성요소

• 테스트 커버리지
• 종류
• 구문 커버리지(Statement Coverage)
• 모든 문장이 실행. 코드의 모든 문장이 적어도 1회 이상 실행
• 결정 커버리지(Decision Coverage)
• 모든 결정이 실행. 모든 결정 분기가 적어도 1회 이상 실행
• 100% 결정 커버리지는 100% 문장 커버리지는 보장함
• 조건 커버리지(Condition Coverage)
• 결정 내부의 모든 조건이 실행
• 결정을 구성하는 조건의 결과가 적어도 1회 이상 나타남.
• 결정 조건 커버리지(Decision Condition Coverage)
• 모든 조건이 실행되고, 모든 결정이 실행됨
• 모든 결정을 포함하고, 결정내 모든 조건의 결과가 나타남
• 변형 결정 조건 커버리지(Modified Decision Condition Coverage)
• 결정 내부의 하나의 조건이 다른 조건과 무관하게 결정에 영향을 주는 경우 추가
• 가장 효율적임
• 다중 조건 커버리지(Multiple Condition Coverage)
• 모든 조합
• 가장 강력하나 비용이 많이 듬

• 참고 : https://brunch.co.kr/@cheuora/23

• 뮤테이션 테스트(Mutation Test)
• 의도적인 변경(Mutant)를 가하여 테스트 케이스의 적합성을 판단하기 위함
• 뮤턴트(돌연변이)를 생성
• 테스트 결과의 신뢰성 확보가 목적임
• 비버깅
• 의도적인 오류코드를 삽입하고 테스트를 통해 잔존 오류를 도출하는 기법
• 의도적 오류코드 삽입
• 잔존 오류 추정 및 배포시기 결정을 위한 목적

• 커서리 테스트(Cursory Test)
• 개발자가 테스트의 주체가 되어 문서화된 테스트 케이스 없이 주요 모듈 단위로 진행하는 즉흥적인 테스트
• 새너티 테스트 이전에 실시함
• 스모그 테스트
• 빌드 초기에 테스트 대상이 테스트가 가능한 상태인지 점검하기 위해 주요한 부분을 확인하는 테스트.
• 개발자나 테스터가 수행
• 본격적인 테스트에 앞서, 대상의 안정성을 테스트 하기 위함
• 보통 문서화 된 테스트 케이스 사용
• 회귀 테스트의 부분 집합
• 전체 시스템을 대상으로 함
• 새너티 테스트(Sanity Test)
• 여러번의 빌드과정 진행된 안정빌드에서 새로운 기능이 오류가 없는지 확인
• 테스터가 수행
• 본격적인 테스트에 앞서, 대상의 합리성을 테스트 하기 위함
• 보통 문서화 되지 않고, 즉흥적인 테스트 
• 인수 테스트의 부분 집합
• 시스템의 일부를 대상으로 함

• 회귀 테스트(Regression Test)
• 테스트된 시스템에 기능을 추가/수정한 다음 Side-effect, Ripple-effect가 없는지 확인하는 반복점진적 테스트 방법

• 결함 주입 (Fault Injection)
• 시스템이 정상적으로 동작되는 동안 결함을 강제로 발생시켜 시스템의 반응(강건성: Robustness)를 확인. 
• 시스템의 신뢰성을 평가하는 방법.